- Where are the exception-objects allocated? - 14 Updates
- std::atomic<T>::is_lock_free() - 1 Update
- Regal eagle / American cloud - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 05:59PM +0100 Can anyone tell me what would be a proper way to allocate storage for an exception-object being thrown without causing that this allocation might fail? And remember that these objects even have to live longer than a thread because you might refer to it by an std::exception_ptr. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 13 10:10AM -0800 On Wednesday, 13 November 2019 18:59:58 UTC+2, Bonita Montero wrote: > allocation might fail? And remember that these objects even have > to live longer than a thread because you might refer to it by > an std::exception_ptr. Does not matter. Implementation makes copy of it as temporary object in unspecified storage during throw expression. Implementation destroys it when last exception_ptr to it is destroyed or when catch clause that caught it is left without rethrow ... whatever happens last. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 07:14PM +0100 >> to live longer than a thread because you might refer to it by >> an std::exception_ptr. > Does not matter. ... It does matter because it is interesting and no one seems to know it. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 13 10:18AM -0800 On Wednesday, November 13, 2019 at 11:59:58 AM UTC-5, Bonita Montero wrote: > allocation might fail? And remember that these objects even have > to live longer than a thread because you might refer to it by > an std::exception_ptr. Exception objects are not created by user code; they are temporary objects created by the implementation, copy-initialized by the expression passed to the throw expression. It is unspecified how the implementation allocates the storage that they are stored in. The relevant wording of the standard is: 123456789012345678901234567890123456789012345678901234567890123456789012 "3 Throwing an exception copy-initializes (11.6, 15.8) a temporary object, called the exception object. An lvalue denoting the temporary is used to initialize the variable declared in the matching handler (18.3). If the type of the exception object would be an incomplete type or a pointer to an incomplete type other than cv void the program is ill- formed. 4 The memory for the exception object is allocated in an unspecified way, except as noted in 6.7.4.1." (18.1). |
| "Öö Tiib" <ootiib@hot.ee>: Nov 13 10:24AM -0800 On Wednesday, 13 November 2019 20:15:05 UTC+2, Bonita Montero wrote: > >> an std::exception_ptr. > > Does not matter. ... > It does matter because it is interesting and no one seems to know it. I answered precisely why and you snipped it and then claimed that I did not know it? :D You can not allocate these objects, Implementation does it into unspecified storage. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 07:27PM +0100 >>> Does not matter. ... >> It does matter because it is interesting and no one seems to know it. > I answered precisely ... "unspecified storage" isn't a precise answer. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 07:28PM +0100 > objects created by the implementation, copy-initialized by the > expression passed to the throw expression. It is unspecified how the > implementation allocates the storage that they are stored in. ... I know that this is unspecified. But I'm interested how this is actually implemented. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 13 10:40AM -0800 On Wednesday, 13 November 2019 20:27:47 UTC+2, Bonita Montero wrote: > >> It does matter because it is interesting and no one seems to know it. > > I answered precisely ... > "unspecified storage" isn't a precise answer. It is precise answer to question asked. If you want to know something that you did not ask then sorry, I'm no psychiatist. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 13 10:44AM -0800 On Wednesday, November 13, 2019 at 1:28:54 PM UTC-5, Bonita Montero wrote: > > implementation allocates the storage that they are stored in. ... > I know that this is unspecified. > But I'm interested how this is actually implemented. Then you need to be specific about which implementations you're most interested in. For best results, you should ask in forums that are specific to those implementations. Those kinds of details are not widely known, because ordinary developers have no need to know them, so the people who do know such details are far easier to find in such specialized forums, rather than in this one. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 07:44PM +0100 >>> I answered precisely ... >> "unspecified storage" isn't a precise answer. > It is precise answer to question asked. ... "unspecified" isn't precise. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 07:46PM +0100 >> I know that this is unspecified. >> But I'm interested how this is actually implemented. > Then you need to be specific about which implementations you're most interested in. For best results, you should ask in forums that are specific to those implementations. Those kinds of details are not widely known, because ordinary developers have no need to know them, so the people who do know such details are far easier to find in such specialized forums, rather than in this one. I'm not interested in some particular implementation but in feasible implementations. I thought someone here would be so creative as to have some adequate ideas. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 08:06PM +0100 > I'm not interested in some particular implementation but in feasible > implementations. I thought someone here would be so creative as to > have some adequate ideas. I just found this (https://libcxxabi.llvm.org/spec.html): | void* __cxa_allocate_exception(size_t thrown_size) throw(); | Effects: Allocates memory to hold the exception to be thrown. | thrown_size is the size of the exception object. Can allocate | additional memory to hold private data. If memory can not be | allocated, call std::terminate(). | Returns: A pointer to the memory allocated for the exception object. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 13 11:36AM -0800 On Wednesday, 13 November 2019 20:46:58 UTC+2, Bonita Montero wrote: > I'm not interested in some particular implementation but in feasible > implementations. I thought someone here would be so creative as to > have some adequate ideas. Huh? Each implementation does something feasible. IIRC then gcc version where I looked in tried first to malloc and if that failed then tried to use emergency buffer that it had reserved for desperate times and if that was used up then called std::terminate. |
| scott@slp53.sl.home (Scott Lurndal): Nov 13 07:41PM >rdinary developers have no need to know them, so the people who do know suc= >h details are far easier to find in such specialized forums, rather than in= > this one. Or BM could simply download the compiler sources and figure it out. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 13 06:34AM +0100 > When is_always_lock_free is false, the functions just *might* return > true in some cases and false in others. I see no logical reason why the machine should determine at #runtime if an atomic<T> can do lock-free operations. |
| Keith Thompson <kst-u@mib.org>: Nov 12 03:54PM -0800 > I installed gcc10 on a FreeBSD 12.1 machine. That machine also has > gcc9.2 on it. When I try to use g++10, I get an error that > it cannot execute 'cc1plus' execvp: No such file or directory How did you install gcc10? I'm not very familiar with FreeBSD, but on some systems "gcc" and "g++" are separate packages. cc1plus is the C++ frontend, invoked by the g++ command. It's typically installed under a "libexec" directory, so g++ can find it but it's not in your $PATH. If you installed gcc-10 with support for C but not for C++, that could explain what you saw -- except that the "g++10" command itself probably shouldn't have been visible. This might be a better question for a Unix or FreeBSD forum. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| 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