- "std::format in C++20" by Peter Gottschling - 15 Updates
- basic_ofstream(const basic_ofstream&) = delete - 2 Updates
| Cholo Lennon <chololennon@hotmail.com>: Oct 06 10:17PM -0300 On 10/6/20 6:06 PM, Lynn McGuire wrote: > "Peter is the author of the must-read book "Discovering Modern C++" for > professional C++ developers." > https://www.amazon.com/Discovering-Modern-Scientists-Programmers-Depth/dp/0134383583 A good complement for the Peter's post is this (relatively short) talk from CppCon 2020: "C++20 String Formatting Library: An Overview and Use with Custom Types" by Marc Gregoire https://youtu.be/IdM0Z2a4fjU I have to check it, but I am impressed by its speed (at least by what Marc Gregoire have said) -- Cholo Lennon Bs.As. ARG |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 07 02:34AM -0700 On Tuesday, October 6, 2020 at 5:06:40 PM UTC-4, Lynn McGuire wrote: > "Today, I'm happy to present Peter Gottschling's guest post to the new > formatting library in C++20: std::format. Thanks to std::format, text > formatting becomes in C++20 as easy as in Python." Given that the direction in modern C++ seemed to be to provide non-throwing alternatives, notably in the filesystem library and the thread support library, I was surprised that the format library only supports exceptions to report errors. Daniel |
| Bo Persson <bo@bo-persson.se>: Oct 07 01:04PM +0200 > alternatives, notably in the filesystem library and the thread support > library, I was surprised that the format library only supports exceptions to > report errors. Perhaps it has something to do with how "exceptional" an error is? For filesystem, a "file not found" status could be quite common and pretty easy to handle. Like ask the user to try some other name. In the format library, about the only error is "incorrect format string". Definitely not an expected error and rather hard to handle if you get it as a return value. Bo Persson |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 07 06:25AM -0700 On Wednesday, October 7, 2020 at 7:05:09 AM UTC-4, Bo Persson wrote: > Perhaps it has something to do with how "exceptional" an error is? > For filesystem, a "file not found" status could be quite common and > pretty easy to handle. Like ask the user to try some other name. The filesystem API supports, e.g., namespace fs = std::filesystem; std::error_code ec; fs::directory_iterator it("foo", ec); // check ec fs::directory_iterator end; while (it != end) { it.increment(ec); // check ec } I doubt if the primary motivation here is ease of handling, as opposed to allowing exceptions to be avoided altogether. > In the format library, about the only error is "incorrect format > string". Definitely not an expected error and rather hard to handle if > you get it as a return value. For those that have to disable exceptions, which includes a significant portion of the C++ community including many game developers, an std::terminate seems a heavy price to pay for a format error. Daniel |
| scott@slp53.sl.home (Scott Lurndal): Oct 07 03:47PM >"std::format in C++20" by Peter Gottschling > http://www.modernescpp.com/index.php/std-format-in-c-20 Peter offers two reasons against using printf/snprintf: 1) It can't be used with user types and 2) It's not type-safe. Neither reason is fully true nor particularly compelling. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 07 06:18PM +0100 On 07/10/2020 12:04, Bo Persson wrote: >> report errors. > Perhaps it has something to do with how "exceptional" an error is? > For filesystem, a "file not found" status could be quite common and pretty easy to handle. Like ask the user to try some other name. I would argue having a file not found exception when attempting to open a file is perfectly acceptable: where does it say that all exceptions must be regarded as fatal? > In the format library, about the only error is "incorrect format string". Definitely not an expected error and rather hard to handle if you get it as a return value. /Flibble -- ¬ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 07 11:03AM -0700 > 1) It can't be used with user types and > 2) It's not type-safe. > Neither reason is fully true nor particularly compelling. Can you expand on that? It seems to me that both are true and compelling. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 07 07:05PM +0100 On 07/10/2020 16:47, Scott Lurndal wrote: > 1) It can't be used with user types and > 2) It's not type-safe. > Neither reason is fully true nor particularly compelling. Bullshit. /Flibble -- ¬ |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 07 06:41PM >> Perhaps it has something to do with how "exceptional" an error is? >> For filesystem, a "file not found" status could be quite common and >> pretty easy to handle. Like ask the user to try some other name. How often is an interactive user really present when a file is opened? Never, in any of my programs. I think a better argument is if handling of the error is likely to be handled locally, rather than after a lot of stack unwinding. > significant portion of the C++ community including many game > developers, an std::terminate seems a heavy price to pay for a > format error. Didn't that ship sail decades ago? Most of the standard library cannot be used without exceptions, so why should this part be different? (Not that I care about this part of C++20. I won't have chance to use it anytime soon, I'm happy with the Unix functions for this, and I've been disappointed by most Boost libraries I've tried (this one is from Boost, right?).) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 07 07:03PM On Tue, 2020-10-06, Lynn McGuire wrote: > "Today, I'm happy to present Peter Gottschling's guest post to the new > formatting library in C++20: std::format. Thanks to std::format, text > formatting becomes in C++20 as easy as in Python." Stuff like this: print("Hello, {name}! The answer is {number}. Goodbye, {name}.\n", arg("name", name), arg("number", number)); Which is indeed like the currently popular Python string formatting interface. Personally, I get more and more disappointed with every new take on string formatting. I prefer Python's earlier[1], more printf-like string formatting. Printf-style has lots of things speaking for it: available in most languages I care about (from the shell to C), compact and well-known since the 1970s. I would have been happy with a variant which let %s work for const char*, std::string (and string_view) and any T which can be streamed. At least if g++ had format string analysis like it does for std::sprintf. Perhaps Boost.format's printf-like variant does what I want. I was under the impression that it was vaguely defined and only vaguely printf-like, but when I check now the documentation says it implements Unix98 printf. Disclaimer: I /am/ happy with defining operator<< for my types, and I do it a lot. /Jorgen [1] It's still there, because TMTOWTDI! -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Juha Nieminen <nospam@thanks.invalid>: Oct 07 07:09PM >> Neither reason is fully true nor particularly compelling. > Can you expand on that? It seems to me that both are true and > compelling. I assume that for the first one he's talking about the workaround of implementing some kind of "toString()" function for the custom type, and using "%s" in the format string for it, so you do it like: std::printf("The value is %s\n", theValue.toString().c_str()); Of course there are multitudes of problems with that, even if we disregard the efficiency problem of creating and destroying a dynamically allocated string there. For one, it cannot easily be used in generic code where you don't know the actual type of the thing being printed. In other words, compare: template<typename T> void foo(const T& value) { // This will work with standard types and custom types alike std::cout << value << "\n"; } to: template<typename T> void foo(const T& value) { std::printf("???\n", value); } I suppose you could devise a rather complicated system where can write something like: template<typename T> void foo(const T& value) { std::printf("%s\n", toString(value)); } The problem with this is that formatting options will not be passed to that toString() function, so it will not know if you want eg. to have a minimum width, a filler character, or output in hexadecimal. Another problem is that this kind of toString() function doesn't have access to the file handle / stream, so it can't eg. call fwrite/ostream::write() on it, if it wanted, or anything else it could want to do with it. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 07 12:25PM -0700 On Wednesday, October 7, 2020 at 2:41:38 PM UTC-4, Jorgen Grahn wrote: > > developers, an std::terminate seems a heavy price to pay for a > > format error. > Didn't that ship sail decades ago? I don't think so. If anything, I think the practice of disabling exceptions has increased over the last decade, judging from reddit discussions, requests for open source projects to support throws become calls to std::terminate, and the extent to which projects have moved to accommodate that. > Most of the standard library cannot be used without exceptions, Well, it can, if exceptions are disabled, throws become calls to std::terminate. According to Herb Sutter, if C++ allowed not throwing on precondition violations and also not on out of memory violations, the vast majority of all C++ standard library functions can be noexcept. He described progress to that end in this article: https://herbsutter.com/2018/07/ > so why should this part be different? Much of the post C++11 direction of the standard library has been to provide alternatives to throwing, seen in the filesystem library and the thread support library, so why should this part be different? > (this one is from Boost, right?).) No. From https://github.com/fmtlib/fmt. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 07 09:07PM +0100 > requests for open source projects to support throws become calls to > std::terminate, and the extent to which projects have moved to > accommodate that. Bullshit. Exceptions remain the superior error handling mechanism and that will not change anytime soon. > Much of the post C++11 direction of the standard library has been > to provide alternatives to throwing, seen in the filesystem library and > the thread support library, so why should this part be different? More bullshit. std::filesystem provides overloads of all functions, one taking an error code that doesn't throw and one that throws: The overload that does not take a std::error_code& parameter throws filesystem_error on underlying OS API errors, constructed with p as the first path argument and the OS error code as the error code argument. The overload taking a std::error_code& parameter sets it to the OS API error code if an OS API call fails, and executes ec.clear() if no errors occur. Any overload not marked noexcept may throw std::bad_alloc if memory allocation fails. Enough with the bullshit already. Exceptions are great. /Flibble -- ¬ |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 07 01:40PM -0700 On Wednesday, October 7, 2020 at 4:08:16 PM UTC-4, Mr Flibble wrote: > > the thread support library, so why should this part be different? > More bullshit. std::filesystem provides overloads of all functions, > one taking an error code that doesn't throw and one that throws: Precisely my point :-) > Enough with the bullshit already. Exceptions are great. From some points of view, not others. But more to the point, given two things: One, the standard committee's attention to "gradually switching precondition violations from exceptions to contracts" that "promises to eventually remove a majority of all exceptions thrown by the standard library", as discussed by Herb Sutter in https://herbsutter.com/2018/07/, and two, the fact that the post C++11 direction appears to be to provide new features with alternative non throwing API's, given that, it seems strange that we now have a format library that only throws. Although I note that there is a proposal to replace some uses of std::format_error with compile-time format string checks. Daniel |
| scott@slp53.sl.home (Scott Lurndal): Oct 07 10:08PM >> Neither reason is fully true nor particularly compelling. >Can you expand on that? It seems to me that both are true and >compelling. Juha touched on 1. to_string() or even "cast" operator overrides in some cases. for 2, gcc and clang and others support the ability warn if the printf specifier doesn't match the type of the associated argument. Frankly, in over thirty years of production C++ programming, and extensive use of snprintf therein, neither of those issues has been compelling enough to switch to the "<<" nonsense. It may be compelling for someone just learning the language, perhaps, but for an experienced programmer? it's just a blip. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 07 06:25AM > ofstream xml_file(xml_filepath.c_str()); > print(xml_file, doc, 0); > I recive error: We are supposed to guess how that print() function is declared? |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 07 09:10AM +0200 >> print(xml_file, doc, 0); >> I recive error: > We are supposed to guess how that print() function is declared? You don't have to know it exactly, but it takes a ofstream -object without a reference for sure. |
| 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