Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Where are the exception-objects allocated?
141 views
Skip to first unread message
Bonita Montero
Nov 13, 2019, 11:59:58 AM11/13/19
to
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.
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
Nov 13, 2019, 1:10:50 PM11/13/19
to
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
Nov 13, 2019, 1:15:05 PM11/13/19
to
> On Wednesday, 13 November 2019 18:59:58 UTC+2, Bonita Montero wrote:
>> 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.
> Does not matter. ...
>> 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.
It does matter because it is interesting and no one seems to know it.
James Kuyper
Nov 13, 2019, 1:18:35 PM11/13/19
to
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
Nov 13, 2019, 1:24:45 PM11/13/19
to
I did not know it? :D You can not allocate these objects,
Implementation does it into unspecified storage.
Bonita Montero
Nov 13, 2019, 1:27:47 PM11/13/19
to
>>> On Wednesday, 13 November 2019 18:59:58 UTC+2, Bonita Montero wrote:
>>>> 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.
>>> Does not matter. ...
>> It does matter because it is interesting and no one seems to know it.
> I answered precisely ...
>>>> 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.
>>> Does not matter. ...
>> It does matter because it is interesting and no one seems to know it.
"unspecified storage" isn't a precise answer.
Bonita Montero
Nov 13, 2019, 1:28:54 PM11/13/19
to
>> 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.
> 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. ...
>> 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.
> 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
I know that this is unspecified.
But I'm interested how this is actually implemented.
Öö Tiib
Nov 13, 2019, 1:40:55 PM11/13/19
to
that you did not ask then sorry, I'm no psychiatist.
James Kuyper
Nov 13, 2019, 1:44:26 PM11/13/19
to
Bonita Montero
Nov 13, 2019, 1:45:05 PM11/13/19
to
>>>>> On Wednesday, 13 November 2019 18:59:58 UTC+2, Bonita Montero wrote:
>>>>>> 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.
>>>>> 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.
> It is precise answer to question asked. ...
>>>>>> 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.
>>>>> 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.
"unspecified" isn't precise.
Bonita Montero
Nov 13, 2019, 1:46:58 PM11/13/19
to
implementations. I thought someone here would be so creative as to
have some adequate ideas.
Bonita Montero
Nov 13, 2019, 2:06:32 PM11/13/19
to
> 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):
> implementations. I thought someone here would be so creative as to
> have some adequate ideas.
| 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
Nov 13, 2019, 2:36:39 PM11/13/19
to
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 Lurndal
Nov 13, 2019, 2:41:39 PM11/13/19
to
James Kuyper <james...@alumni.caltech.edu> writes:
>On Wednesday, November 13, 2019 at 1:28:54 PM UTC-5, Bonita Montero wrote:
>> >> 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.
>>=20
>On Wednesday, November 13, 2019 at 1:28:54 PM UTC-5, Bonita Montero wrote:
>> >> 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.
>> > 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. ...
>>=20
>> > 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.
>
>Then you need to be specific about which implementations you're most intere=
>> But I'm interested how this is actually implemented.
>
>sted in. For best results, you should ask in forums that are specific to th=
>ose implementations. Those kinds of details are not widely known, because o=
>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.
Chris M. Thomasson
Nov 14, 2019, 12:58:40 AM11/14/19
to
Ian Collins
Nov 14, 2019, 2:11:37 AM11/14/19
to
--
Ian.
Alf P. Steinbach
Nov 14, 2019, 6:42:18 AM11/14/19
to
class by using `std::runtime_error` or a derived class.
It can of course throw when the original exception is created, but after
that it's guaranteed that copying does not throw:
C++17 §21.8.2/2:
“Each standard library class T that derives from class exception shall
have a publicly accessible copy constructor and a publicly accessible
copy assignment operator that do not exit with an exception.”
For other data you have to ensure this guarantee yourself.
A reasonable approach is to minimize the amount of other data in an
exception.
- Alf
Bonita Montero
Nov 14, 2019, 7:07:38 AM11/14/19
to
> C++17 §21.8.2/2:
> “Each standard library class T that derives from class exception shall
> have a publicly accessible copy constructor and a publicly accessible
> copy assignment operator that do not exit with an exception.”
1. I'm talking about the storage for the exception-object itself;
> “Each standard library class T that derives from class exception shall
> have a publicly accessible copy constructor and a publicly accessible
> copy assignment operator that do not exit with an exception.”
this isn't allocated by your own code but the rundime-library.
2. I just posted my parallel merge-sort-algorithm. It gathers the
exceptions which might occur in the sorting-threads in a single
pre-allocated vector of exception_ptr's and moves this vector
inside the exception which might be thrown later. If I would
provide a copy-costructor or assignment-operator, this vector
would be copied and an exception might get thrown. This might
occur when you don't catch the exception by reference (I don't
see any reason to catch exception-objects by value anyway). So
there are good reasons to not to provide both.
Sam
Nov 15, 2019, 6:36:13 AM11/15/19
to
yourself.
If you are so desperate to find out, that would be the only way how;
excepting the very unlikely possibility that whoever wrote that is around
here.
Otherwise: nobody else knows, or cares.
Bonita Montero
Nov 15, 2019, 7:33:42 AM11/15/19
to
>> "unspecified" isn't precise.
> It is precise enough for every C++ developer.
As I said I didn't ask to develop according to that but just
> It is precise enough for every C++ developer.
for curiosity. And in this sense the answer isn't precise.
Bonita Montero
Nov 15, 2019, 7:35:43 AM11/15/19
to
>> But I'm interested how this is actually implemented.
> Some years ago I have tested this with g++. Normal malloc(), if this
> misses, special static memory area, if this misses, normal malloc() ---
> endless loop. Yes, your found __cxa_allocate_exception(). I am not sure,
> but I can't remember of calling a user defined handling of this situation.
> That IS a thing every ordinary developer has to know, James.
> My only Idea is a handler, so that another part of the program can free(),
> but that would guarantee nothing. Or to loop and wait as it did.
I don't believe that they actually do a infinite malloc()-loop.
As I said LLVM's libc++ uses a special function like malloc and
if it fails std::terminate() is simply called.
Bonita Montero
Nov 15, 2019, 7:37:28 AM11/15/19
to
> Feel free to download the source code to gcc and libstdc++, and see for
> yourself.
Read the complete thread before you post!
> yourself.
I already 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.
James Kuyper
Nov 15, 2019, 10:01:11 AM11/15/19
to
On 11/15/19 6:34 AM, Sam wrote:
> Bonita Montero writes:
>
>>>>>>> On Wednesday, 13 November 2019 18:59:58 UTC+2, Bonita Montero wrote:
>>>>>>>> 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.
>>
>>>>>>> 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.
>>
>>> It is precise answer to question asked. ...
>>
>> "unspecified" isn't precise.
>
> It is precise enough for every C++ developer.
Agreed. Implementation-defined behavior is
> Bonita Montero writes:
>
>>>>>>> On Wednesday, 13 November 2019 18:59:58 UTC+2, Bonita Montero wrote:
>>>>>>>> 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.
>>
>>>>>>> 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.
>>
>>> It is precise answer to question asked. ...
>>
>> "unspecified" isn't precise.
>
> It is precise enough for every C++ developer.
"unspecified behavior where each implementation documents how the choice
is made" (3.4.1).
The committee specifies that something is implementation-defined
whenever it believes that there can be a good reason why the developer
might need to know which choice an implementation has made.
It follows that if the behavior is unspecified, and NOT
implementation-defined, the committee believes that developers will
generally not need to know which choice was made.
That's relevant here, because the way memory is allocated for exception
objects is a prime example of that second category. Since most
developers don't need to know, most developers don't know. Just a few
experts who know a lot more about how a given implementation works than
most people, will have the answers to Bonita's question, and most of
those people are much easier to find in a forum specific to the
implementation that they're experts on, than they would be in this
newsgroup.
Bonita Montero
Nov 15, 2019, 10:19:29 AM11/15/19
to
> The committee specifies that something is implementation-defined
> whenever it believes that there can be a good reason why the developer
> might need to know which choice an implementation has made.
Ar there only idiots discussing here? It doesn't matter if the standard
> whenever it believes that there can be a good reason why the developer
> might need to know which choice an implementation has made.
doesn't say how the exception-objects might be allocated. It is never-
theless an interesting question.
If I had asked how exceptions are implemented with zero overhead when
not thrown I'd got a lot of answers without the stupid objection, that
the standard doesn't make any statements about this.
Some folks here just can't bear that there's a question the can't
answer which frustrades them that the say that this question doesn't
matter.
> That's relevant here, because the way memory is allocated for exception
> objects is a prime example of that second category. Since most
> developers don't need to know, most developers don't know. Just a few
> experts who know a lot more about how a given implementation works than
> most people, will have the answers to Bonita's question, and most of
> those people are much easier to find in a forum specific to the
> implementation that they're experts on, than they would be in this
> newsgroup.
(which reaches a lot more developers) from someone else some time ago
yielded no satisfying annswer. So no one seems to be concerned about
that.
But I think every impementation handels this issue like clang / libc++
and does a dynamic allocation, thereby assuming that the small allo-
cation an exception-object usually needs is very unlikely to fail.
Sam
Nov 15, 2019, 11:12:22 AM11/15/19
to
Bonita Montero writes:
>> The committee specifies that something is implementation-defined
>> whenever it believes that there can be a good reason why the developer
>> might need to know which choice an implementation has made.
>
> Ar there only idiots discussing here?
No, but you're doing your best to tip the scales.
>> The committee specifies that something is implementation-defined
>> whenever it believes that there can be a good reason why the developer
>> might need to know which choice an implementation has made.
>
> Ar there only idiots discussing here?
> It doesn't matter if the standard
> doesn't say how the exception-objects might be allocated. It is never-
> theless an interesting question.
you earned it. Congratulations.
> I didn't find a forum. And even the same question on Stack Overlfow,
> (which reaches a lot more developers) from someone else some time ago
> yielded no satisfying annswer. So no one seems to be concerned about
> that.
about you?
Sam
Nov 15, 2019, 11:14:42 AM11/15/19
to
Bonita Montero writes:
>> Feel free to download the source code to gcc and libstdc++, and see for
>> yourself.
>
> Read the complete thread before you post!
Unfortunately, I did.
>> Feel free to download the source code to gcc and libstdc++, and see for
>> yourself.
>
> Read the complete thread before you post!
> I already 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.
>
> This looks to me the usual and pragmatical way it is done.
about its business? And after you figure that out, I'm sure you'll be
curious enough to know the precise semantics down to the transistor level.
Bonita Montero
Nov 15, 2019, 11:16:29 AM11/15/19
to
>> Ar there only idiots discussing here?
> No, but you're doing your best to tip the scales.
No, I'm not. It's the folks here that seems to be frustrated about
> No, but you're doing your best to tip the scales.
questions they can't answer.
Bonita Montero
Nov 15, 2019, 11:18:03 AM11/15/19
to
>>> Feel free to download the source code to gcc and libstdc++, and see
>>> for yourself.
>> Read the complete thread before you post!
> Unfortunately, I did.
If you did the above answer would be senseless.
>>> for yourself.
>> Read the complete thread before you post!
> Unfortunately, I did.
>> I already 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.
>> This looks to me the usual and pragmatical way it is done.
> Excellent. Now, aren't you curious how this "__cxa_allocate_exception"
> does about its business? And after you figure that out, I'm sure you'll
> be curious enough to know the precise semantics down to the transistor
> level.
James Kuyper
Nov 15, 2019, 11:45:16 AM11/15/19
to
On Friday, November 15, 2019 at 10:19:29 AM UTC-5, Bonita Montero wrote:
> > The committee specifies that something is implementation-defined
> > whenever it believes that there can be a good reason why the developer
> > might need to know which choice an implementation has made.
>
> Ar there only idiots discussing here? It doesn't matter if the standard
> doesn't say how the exception-objects might be allocated. It is never-
> theless an interesting question.
I'm not denying that it might be an interesting question for some people
> > The committee specifies that something is implementation-defined
> > whenever it believes that there can be a good reason why the developer
> > might need to know which choice an implementation has made.
>
> Ar there only idiots discussing here? It doesn't matter if the standard
> doesn't say how the exception-objects might be allocated. It is never-
> theless an interesting question.
(I'm not particularly interested in it, myselft) - I'm merely explaining
why there are better places to go to get good answers to your question.
If you don't care whether the answers you get are good, or for that
matter, whether you get any answers at all, this is no worse a place to
post them than any other.
> If I had asked how exceptions are implemented with zero overhead when
> not thrown I'd got a lot of answers without the stupid objection, that
> the standard doesn't make any statements about this.
been) implemented with zero overhead has a great deal of bearing upon
whether or not it's a good idea to use them in any particular
circumstance. The zero-overhead approach has the consequence that
exceptions, when used, are generally very slow. I've seen code that
threw and caught an exception within the same function, as a glorified
goto - and the fact that they are very slow is an important reason for
not doing that.
> Some folks here just can't bear that there's a question the can't
> answer which frustrades them that the say that this question doesn't
> matter.
importance for anything I've ever done or could ever imagine doing (I
don't imagine myself working as a developer for a C++ compiler, which is
the only context in which I would be interested in the answer). If it
had ever been important to me, I would have found out.
> > That's relevant here, because the way memory is allocated for exception
> > objects is a prime example of that second category. Since most
> > developers don't need to know, most developers don't know. Just a few
> > experts who know a lot more about how a given implementation works than
> > most people, will have the answers to Bonita's question, and most of
> > those people are much easier to find in a forum specific to the
> > implementation that they're experts on, than they would be in this
> > newsgroup.
>
> I didn't find a forum.
have dozens, if not hundreds of them - the hard part is choosing the
right one (and it IS a hard task). But the best place to find the right
gcc forum is to ask in a gcc forum, and similarly for Microsoft. Keep in
mind that usenet is not the only place to go to for discussion forums -
mailing lists and chat rooms are among the most common alternatives.
James Kuyper
Nov 15, 2019, 11:47:16 AM11/15/19
to
is not very reliable. I recommend not relying on it for anything important.
Sam
Nov 15, 2019, 11:51:40 AM11/15/19
to
Bonita Montero writes:
>>>> Feel free to download the source code to gcc and libstdc++, and see for
>>>> yourself.
>
>>> Read the complete thread before you post!
>
>> Unfortunately, I did.
>
> If you did the above answer would be senseless.
It's not my fault you lack the minimal capacity to understand its brilliance.
>>>> Feel free to download the source code to gcc and libstdc++, and see for
>>>> yourself.
>
>>> Read the complete thread before you post!
>
>> Unfortunately, I did.
>
> If you did the above answer would be senseless.
>>> I already 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.
>>> This looks to me the usual and pragmatical way it is done.
>
>> Excellent. Now, aren't you curious how this "__cxa_allocate_exception" does
>> about its business? And after you figure that out, I'm sure you'll be
>> curious enough to know the precise semantics down to the transistor level.
>
> It's a normal heap-allocation.
that frustrates you. Too bad.
Bonita Montero
Nov 15, 2019, 12:45:48 PM11/15/19
to
>> No, I'm not. It's the folks here that seems to be frustrated about
>> questions they can't answer.
> That suggests that your ability to guess at people's unstated motivations
> is not very reliable.
It is reliable since this can be derived from the kind of answer.
>> questions they can't answer.
> That suggests that your ability to guess at people's unstated motivations
> is not very reliable.
Bonita Montero
Nov 15, 2019, 12:52:48 PM11/15/19
to
> That's because the question of whether or not they can be (and have
> been) implemented with zero overhead has a great deal of bearing upon
> whether or not it's a good idea to use them in any particular
> circumstance. The zero-overhead approach has the consequence that
> exceptions, when used, are generally very slow.
Not true. Exception-handling with concatenated with al TLS-pointer
> been) implemented with zero overhead has a great deal of bearing upon
> whether or not it's a good idea to use them in any particular
> circumstance. The zero-overhead approach has the consequence that
> exceptions, when used, are generally very slow.
to the top stack-frame is also slow.
> I've seen code that threw and caught an exception within the same
> function, as a glorified goto - and the fact that they are very
> slow is an important reason for not doing that.
> It doesn't frustrate me ...
Obviously not you, but others in this thread.
> It doesn't frustrate me that I can't answer it - the answer has no
> importance for anything I've ever done or could ever imagine doing
matter for practical programming. It's just sufficient to know that not
throwing costs nothing, throwing costs a lot and there might be a lot of
unwinding-code. Nevertheless it's interesting to know how it works.
Bonita Montero
Nov 15, 2019, 12:57:03 PM11/15/19
to
>>>>> Feel free to download the source code to gcc and libstdc++, and see
>>>>> for yourself.
>>>> Read the complete thread before you post!
>>> Unfortunately, I did.
>> If you did the above answer would be senseless.
> It's not my fault you lack the minimal capacity to understand its
> brilliance.
Another time: if you had read that I quoted a part of the LLVM-website
>>>>> for yourself.
>>>> Read the complete thread before you post!
>>> Unfortunately, I did.
>> If you did the above answer would be senseless.
> It's not my fault you lack the minimal capacity to understand its
> brilliance.
your posting would be gratuitous.
>>> Excellent. Now, aren't you curious how this
>>> "__cxa_allocate_exception" does about its business? And after you
>>> figure that out, I'm sure you'll be curious enough to know the
>>> precise semantics down to the transistor level.
>> It's a normal heap-allocation.
> Yes, but how does that work? I guess you don't know the answer to that,
> and that frustrates you. Too bad.
the exception-object couldn't be created. There are several heap-alloca-
tion-strategies which are all equally appropriate for this purpose.
Heap-allocation is a different topic.
Mr Flibble
Nov 15, 2019, 4:13:28 PM11/15/19
to
which are specific to a particular implementation and thus off topic here.
/Flibble
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais
“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Chris M. Thomasson
Nov 15, 2019, 4:48:04 PM11/15/19
to
On 11/13/2019 8:59 AM, Bonita Montero wrote:
> 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?
Sometimes, exceptions are banned for certain environments for good reasons.
> 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.
however they want to, as long as it complies to the std. Damn, JG, how
many exceptions would have to be nested to exhaust memory in a thread
such that throw has nothing left? You know the answer right?
I remember doing an excepting thing in C basically abusing
setjmp/longjump. It used TLS.
Better to ask in a compiler group. For instance, I found some odd things
going on in pellesc. Asked over there, and received extremely
informative answers. Well, they said they might get fixed in the next
release. Okay, good enough. :^)
Sam
Nov 15, 2019, 5:18:13 PM11/15/19
to
Bonita Montero writes:
>>>> Excellent. Now, aren't you curious how this "__cxa_allocate_exception" does
>>>> about its business? And after you figure that out, I'm sure you'll be
>>>> curious enough to know the precise semantics down to the transistor level.
>
>>> It's a normal heap-allocation.
>
>> Yes, but how does that work? I guess you don't know the answer to that, and
>> that frustrates you. Too bad.
>
> Doesn't matter. I asked just to know if the throwing might fail because
> the exception-object couldn't be created. There are several heap-alloca-
> tion-strategies which are all equally appropriate for this purpose.
> Heap-allocation is a different topic.
Look, it's ok that you don't know this, and you have no idea how it works.
>>>> Excellent. Now, aren't you curious how this "__cxa_allocate_exception" does
>>>> about its business? And after you figure that out, I'm sure you'll be
>>>> curious enough to know the precise semantics down to the transistor level.
>
>>> It's a normal heap-allocation.
>
>> Yes, but how does that work? I guess you don't know the answer to that, and
>> that frustrates you. Too bad.
>
> Doesn't matter. I asked just to know if the throwing might fail because
> the exception-object couldn't be created. There are several heap-alloca-
> tion-strategies which are all equally appropriate for this purpose.
> Heap-allocation is a different topic.
Nobody's perfect. Don't let it upset you.
Bonita Montero
Nov 16, 2019, 3:01:33 AM11/16/19
to
> The exception object is allocated in unspecified storage the details of
> which are specific to a particular implementation and thus off topic here.
If the discussion of zero-overhead exceptions aren't off-topic here,
> which are specific to a particular implementation and thus off topic here.
my topic is also not off-topic here. Implementation-issues aren't
off-topic here.
Bonita Montero
Nov 16, 2019, 3:04:43 AM11/16/19
to
>> 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?
> Sometimes, exceptions are banned for certain environments for good reasons.
You seem to be confused very often. Are you competing with Melzzzz?
>> for an exception-object being thrown without causing that this
>> allocation might fail?
> Sometimes, exceptions are banned for certain environments for good reasons.
This "answer" has nothing to do with my question.
>> And remember that these objects even have
>> to live longer than a thread because you might refer to it by
>> an std::exception_ptr.
> This is completely up to the implementation. They can store/do things
> however they want to, as long as it complies to the std. Damn, JG, how
> many exceptions would have to be nested to exhaust memory in a thread
> such that throw has nothing left? You know the answer right?
> Better to ask in a compiler group. For instance, I found some odd
> things going on in pellesc. Asked over there, and received extremely
> informative answers. Well, they said they might get fixed in the next
> release. Okay, good enough. :^)
my question is on-topic as well.
Bonita Montero
Nov 16, 2019, 3:05:46 AM11/16/19
to
>> Doesn't matter. I asked just to know if the throwing might fail because
>> the exception-object couldn't be created. There are several heap-alloca-
>> tion-strategies which are all equally appropriate for this purpose.
>> Heap-allocation is a different topic.
> Look, it's ok that you don't know this, and you have no idea how it
> works. Nobody's perfect. Don't let it upset you.
I know different heap-allcoation-strategies.
>> the exception-object couldn't be created. There are several heap-alloca-
>> tion-strategies which are all equally appropriate for this purpose.
>> Heap-allocation is a different topic.
> Look, it's ok that you don't know this, and you have no idea how it
> works. Nobody's perfect. Don't let it upset you.
But how this works isn't related to my initial question.
Bonita Montero
Nov 16, 2019, 2:49:55 PM11/16/19
to
Mr Flibble
Nov 16, 2019, 8:10:12 PM11/16/19
to
🤣
/Flibble
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais
“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais
"Suppose it's all true, and you walk up to the pearly gates, and are
Ian Collins
Nov 16, 2019, 8:32:08 PM11/16/19
to
On 17/11/2019 14:10, Mr Flibble wrote:
> On 17/11/2019 01:08, Sam wrote:
>> Bonita Montero writes:
>>
>>>>>> Look, it's ok that you don't know this, and you have no idea how it
>>>>>> works. Nobody's perfect. Don't let it upset you.
>>>
>>>>> I know different heap-allcoation-strategies.
>>>
>>>> Sure, everyone believes you.
>>>
>>> Slogans like from the scoolyard ...
>>
>> Right. I clearly remember how everyone in the schoolyard always pretended
>> to be experts on heap allocation strategies.
>
> Hmmm, I wonder if emoji works on Usenet. Lets find out:
>
> 🤣
💩
> On 17/11/2019 01:08, Sam wrote:
>> Bonita Montero writes:
>>
>>>>>> Look, it's ok that you don't know this, and you have no idea how it
>>>>>> works. Nobody's perfect. Don't let it upset you.
>>>
>>>>> I know different heap-allcoation-strategies.
>>>
>>>> Sure, everyone believes you.
>>>
>>> Slogans like from the scoolyard ...
>>
>> Right. I clearly remember how everyone in the schoolyard always pretended
>> to be experts on heap allocation strategies.
>
> Hmmm, I wonder if emoji works on Usenet. Lets find out:
>
> 🤣
--
Ian.
Bonita Montero
Nov 17, 2019, 3:18:21 AM11/17/19
to
Bonita Montero
Nov 17, 2019, 10:06:39 AM11/17/19
to
>>> Right. I clearly remember how everyone in the schoolyard always
>>> pretended to be experts on heap allocation strategies.
>> I was talking about you, and you know that.
> Highly-trained professionals have a word for this. It's called
> "projection".
You're not so professional to determine when someone projects
>>> pretended to be experts on heap allocation strategies.
>> I was talking about you, and you know that.
> Highly-trained professionals have a word for this. It's called
> "projection".
something. You're simply an idiot.
Sam
Nov 17, 2019, 4:27:53 PM11/17/19
to
someone to be an idiot? If you're going to stake a position that
professional qualifications are required for a psychological evaluation –
such as whether someone's projecting, or not – shirley you then have to
prove your professional qualifications for diagnosing a case of idiocy.
I'm very convinced that if you demand others to uphold to the highest
standards of professional qualifications, in order to accuse someone of
projection, you most certainly will meet your own standards and be able to
demonstrate your own professional qualifications for determining if
someone's an idiot.
So, let's see them (asking for a friend).
Ian Collins
Nov 17, 2019, 10:29:28 PM11/17/19
to
On 18/11/2019 10:27, Sam wrote:
> Bonita Montero writes:
>
>>
> Bonita Montero writes:
>
>>
>> You're not so professional to determine when someone projects
>> something. You're simply an idiot.
>
> And what exactly would be your professional qualifications for diagnosing
> someone to be an idiot?
A master's in trolling?
>> something. You're simply an idiot.
>
> And what exactly would be your professional qualifications for diagnosing
> someone to be an idiot?
--
Ian.
Bonita Montero
Nov 18, 2019, 1:02:02 AM11/18/19
to
> And what exactly would be your professional qualifications for
> diagnosing someone to be an idiot? If you're going to stake a position
> that professional qualifications are required for a psychological
> evaluation – such as whether someone's projecting, or not – shirley you
> then have to prove your professional qualifications for diagnosing a
> case of idiocy.
> I'm very convinced that if you demand others to uphold to the highest
> standards of professional qualifications, in order to accuse someone of
> projection, you most certainly will meet your own standards and be able
> to demonstrate your own professional qualifications for determining if
> someone's an idiot.
> So, let's see them (asking for a friend).
Ok, idiot wasn't correct; complete idiot would be more appropriate.
> diagnosing someone to be an idiot? If you're going to stake a position
> that professional qualifications are required for a psychological
> evaluation – such as whether someone's projecting, or not – shirley you
> then have to prove your professional qualifications for diagnosing a
> case of idiocy.
> I'm very convinced that if you demand others to uphold to the highest
> standards of professional qualifications, in order to accuse someone of
> projection, you most certainly will meet your own standards and be able
> to demonstrate your own professional qualifications for determining if
> someone's an idiot.
> So, let's see them (asking for a friend).
Sam
Nov 18, 2019, 10:16:37 AM11/18/19
to
a complete idiot? That's good enough. Let's see them, please. Or, in the
alternate, what is your membership number in the American Society of
Standards in Working Idiocy Professional Evaluators; and I'll just look your
membership on their web site.
Bonita Montero
Nov 18, 2019, 10:49:01 AM11/18/19
to
> Oh, so you only have professional qualifications for evaluating if
> someone's a complete idiot? That's good enough. Let's see them, please.
> Or, in the alternate, what is your membership number in the American
> Society of Standards in Working Idiocy Professional Evaluators; and
> I'll just look your membership on their web site.
Everyone with an average knowledge of human nature has this, except you.
> someone's a complete idiot? That's good enough. Let's see them, please.
> Or, in the alternate, what is your membership number in the American
> Society of Standards in Working Idiocy Professional Evaluators; and
> I'll just look your membership on their web site.
Sam
Nov 18, 2019, 11:33:28 AM11/18/19
to
be a member of a professional organization, according to your own words.
I never claimed to be a professional member of any such organization in this
thread. You demanded that I must be one, in order to diagnose your case of
projection, and I did not dispute that I never claimed to be one.
I still don't quite understand your reluctance to show your proof of
membership in the American Society of Standards in Working Idiocy
Professional Evaluators. Are you or are you not a member? By your own rules,
you must be one, in order to call someone either an idiot, or a complete
idiot (still not sure about that one).
Or, maybe you just expect me to take your word for it?
Bonita Montero
Nov 18, 2019, 11:41:18 AM11/18/19
to
> I never claimed to be a professional member of any such organization in
> this thread. You demanded that I must be one, in order to diagnose your
> case of projection, and I did not dispute that I never claimed to be one.
In Germany we call diagnoses like yours as "kitchen psychology" which
> this thread. You demanded that I must be one, in order to diagnose your
> case of projection, and I did not dispute that I never claimed to be one.
could be translated ad layman's psychology. And those diagnoses are
not even inprecise, but usually nonsense.
You're simply a stupid person.
Sam
Nov 18, 2019, 11:58:16 AM11/18/19
to
Bonita Montero writes:
>> I never claimed to be a professional member of any such organization in
>> this thread. You demanded that I must be one, in order to diagnose your
>> case of projection, and I did not dispute that I never claimed to be one.
[ important context restored ]
>> I never claimed to be a professional member of any such organization in
>> this thread. You demanded that I must be one, in order to diagnose your
>> case of projection, and I did not dispute that I never claimed to be one.
>> I still don't quite understand your reluctance to show your proof of
>> membership in the American Society of Standards in Working Idiocy
>> Professional Evaluators. Are you or are you not a member? By your own
>> rules, you must be one, in order to call someone either an idiot, or
>> a complete idiot (still not sure about that one).
>
> In Germany we call diagnoses like yours as "kitchen psychology" which
> could be translated ad layman's psychology. And those diagnoses are
> not even inprecise, but usually nonsense.
> You're simply a stupid person.
It does seem, for whatever reason, you're trying to deny your A.S.S.W.I.P.E.
> could be translated ad layman's psychology. And those diagnoses are
> not even inprecise, but usually nonsense.
> You're simply a stupid person.
membership. Why would you do this? You should be proud for being a card-
carrying A.S.S.W.I.P.E. It's a major accomplishment, that few achieve in
their lifetime.
Bonita Montero
Nov 18, 2019, 12:15:31 PM11/18/19
to
> It does seem, for whatever reason, you're trying to deny your
> A.S.S.W.I.P.E. membership. Why would you do this? You should be proud
> for being a card-carrying A.S.S.W.I.P.E. It's a major accomplishment,
> A.S.S.W.I.P.E. membership. Why would you do this? You should be proud
> that few achieve in their lifetime.
Youre a stupid, immature troll.
Keith Thompson
Nov 18, 2019, 1:05:21 PM11/18/19
to
if you didn't quote them.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Sam
Nov 18, 2019, 6:21:42 PM11/18/19
to
Keith Thompson writes:
> Sam, please stop feeding the troll. I wouldn't see Bonita's posts
> if you didn't quote them.
I do not go out of my way to respond (or not respond) to anyone, in
> Sam, please stop feeding the troll. I wouldn't see Bonita's posts
> if you didn't quote them.
particular. That, I can state affirmatively. I will not set up a filter, and
flame away at that low-information poster's every outburst.
But, if I happen to stumble across something response-worthy and I choose to
respond, then I will. Especially if the resulting back-and-forth promises to
be quite entertaining. And if seeing someone else's writings indirectly
irritates someone else, as a result, this is unfortunate; but they are free
to make their own decisions (and also threaten to ban me from offending
their delicate eyeballs, as well, if it makes them feel better).
But I will not refrain from enjoying a cost-free source of cheap
entertainment just because someone else gets upset. It just makes no logical
sense for me to do so.
If someone gets so discombobulated by mere words – and nothing more than
words on the screen – then I truly feel some pity for them. Personally, I
choose to deal with the world at large as it is, both good and bad. I'll
happily give the job of getting triggered by mean words to all the millenial
snowflakes.
P.S. That's a "troll"? Really? Gosh, our standards have sunk by quite a bit.
That entity can't even come up to the ankles of any of the legendary trolls
of yesteryear. Examples provided upon request.
David Brown
Nov 19, 2019, 2:26:45 AM11/19/19
to
On 19/11/2019 00:21, Sam wrote:
> But I will not refrain from enjoying a cost-free source of cheap
> entertainment just because someone else gets upset. It just makes no
> logical sense for me to do so.
>
I appreciate your right to post the way you want here, and I fully
> But I will not refrain from enjoying a cost-free source of cheap
> entertainment just because someone else gets upset. It just makes no
> logical sense for me to do so.
>
appreciate your motive of cheap entertainment. But there comes a point
in which such threads become more akin to Calvin and Hobbes "You're a
potty mouth! No, /you're/ a potty mouth!". Surely that can no longer
be entertaining?
Bonita does not seem to be going anywhere - you'll get plenty of new
chances in the future, and perhaps an opportunity for new and more
varied insults.
Keith Thompson
Nov 19, 2019, 1:29:49 PM11/19/19
to
Sam <s...@email-scan.com> writes:
[..]
seeing you do so here. If your personal entertainment is more
important than sticking to the topic of the newsgroup, I can get
along without seeing any of your contributions, so I'll add you to
my killfile as well.
I find it rude that you impose on the other readers of this
newsgroup the burden of either adjusting their filters or reading
your off-topic and frankly boring "entertainment". I encourage
you to stop, but it will no longer matter to me personally.
Bye.
[...]
[..]
> Keith Thompson writes:
>
>> Sam, please stop feeding the troll. I wouldn't see Bonita's posts
>> if you didn't quote them.
>
> I do not go out of my way to respond (or not respond) to anyone,
> in particular. That, I can state affirmatively. I will not set
> up a filter, and flame away at that low-information poster's
> every outburst.
>
> But, if I happen to stumble across something response-worthy and
> I choose to respond, then I will. Especially if the resulting
> back-and-forth promises to be quite entertaining. And if seeing
> someone else's writings indirectly irritates someone else, as
> a result, this is unfortunate; but they are free to make their
> own decisions (and also threaten to ban me from offending their
> delicate eyeballs, as well, if it makes them feel better).
The purpose of this newsgroup is to discuss C++. I don't recall
>
>> Sam, please stop feeding the troll. I wouldn't see Bonita's posts
>> if you didn't quote them.
>
> I do not go out of my way to respond (or not respond) to anyone,
> in particular. That, I can state affirmatively. I will not set
> up a filter, and flame away at that low-information poster's
> every outburst.
>
> But, if I happen to stumble across something response-worthy and
> I choose to respond, then I will. Especially if the resulting
> back-and-forth promises to be quite entertaining. And if seeing
> someone else's writings indirectly irritates someone else, as
> a result, this is unfortunate; but they are free to make their
> own decisions (and also threaten to ban me from offending their
> delicate eyeballs, as well, if it makes them feel better).
seeing you do so here. If your personal entertainment is more
important than sticking to the topic of the newsgroup, I can get
along without seeing any of your contributions, so I'll add you to
my killfile as well.
I find it rude that you impose on the other readers of this
newsgroup the burden of either adjusting their filters or reading
your off-topic and frankly boring "entertainment". I encourage
you to stop, but it will no longer matter to me personally.
Bye.
[...]
James Kuyper
Nov 22, 2019, 11:08:19 AM11/22/19
to
On 11/18/19 6:21 PM, Sam wrote:
...
To me, it's just annoying, not entertaining.
> ... And if seeing someone else's writings indirectly
do decide to do it, I won't bother announcing that fact, either. I don't
expect people to be afraid of being in my killfile, so I don't see that
I have any leverage for changing their behavior by threatening to put
them there.
...
> But, if I happen to stumble across something response-worthy and I choose to
> respond, then I will. Especially if the resulting back-and-forth promises to
> be quite entertaining. ...
> respond, then I will. Especially if the resulting back-and-forth promises to
To me, it's just annoying, not entertaining.
> ... And if seeing someone else's writings indirectly
> irritates someone else, as a result, this is unfortunate; but they are free
> to make their own decisions (and also threaten to ban me from offending
> their delicate eyeballs, as well, if it makes them feel better).
I won't threaten to ban you. I'll either do it, or not do it, and if I
> to make their own decisions (and also threaten to ban me from offending
> their delicate eyeballs, as well, if it makes them feel better).
do decide to do it, I won't bother announcing that fact, either. I don't
expect people to be afraid of being in my killfile, so I don't see that
I have any leverage for changing their behavior by threatening to put
them there.
Sam
Nov 22, 2019, 8:49:29 PM11/22/19
to
James Kuyper writes:
> On 11/18/19 6:21 PM, Sam wrote:
> ...
> > But, if I happen to stumble across something response-worthy and I choose
> to
> > respond, then I will. Especially if the resulting back-and-forth promises
> to
> > be quite entertaining. ...
>
> To me, it's just annoying, not entertaining.
There are, I suppose, some things around here that I might also find
> On 11/18/19 6:21 PM, Sam wrote:
> ...
> > But, if I happen to stumble across something response-worthy and I choose
> to
> > respond, then I will. Especially if the resulting back-and-forth promises
> to
> > be quite entertaining. ...
>
> To me, it's just annoying, not entertaining.
annoying.
But I can't quite figure out why I need to announce this. I'm under no
illusion that anyone cares whether I find something annoying, or not. So,
what's the purpose in making this kind of an announcement? I don't get it. I
find something interesting or entertaining, I respond. If not, I just move
on.
0 new messages