Prev: How to embed a word document in CView
Next: _ATL_NO_EXCEPTIONS conflict
From: Giovanni Dicanio on 25 Jun 2010 10:40
On 25/06/2010 13:48, Jeff Flinn wrote:

> The generally accepted approach is to throw by value, which you've done,
> and catch by [const] ref. This is contrary to most of Microsoft's code,
> which new's up an exception on the heap and throws the pointer.

This is not "Microsoft's code", it is MFC's code.
There is also Microsoft's code which correctly throws on the stack (like
ATL exceptions).

I'm not sure (probably Joe or other long-timers know better), but it
seems to me that MFC used exceptions before the C++ standard defined
them and/or the usual C++ patterns matured enough.

Giovanni

From: RB on 25 Jun 2010 12:23
Ok, well all of this is enlightening given I did not even know one
could return the definition of class and have it constructed on the stack.
So a reference does help (for the reason you gave) even though it may
be a small copy, that is interesting. But then I shouldn't have equated the
stack ownership as any ramification since other items are sometimes on
the stack also. A reference is a reference I guess, no matter where it references.
Thanks for the reply, I don't have any current questions.


From: RB on 25 Jun 2010 12:31

> The generally accepted approach is to throw by value, which you've done,
> and catch by [const] ref.

Thanks for the reply,
All of this is enlightening given I did not even know one could return the
definition of class and have it constructed on the stack. At first I thought
it is already on the stack so why reference it, but then I shouldn't have
equated the stack ownership as any ramification since other items are sometimes
on the stack also. A reference is a reference I guess, no matter where it references.

> Why would your object ever need to be "fairly large"?

Not sure if it would, I know the one I currently experimenting with certainly
isn't.

> You might want to get a book and/or google C++ exceptions. To do right, an
> exception architecture takes thought and effort. Jeff

I don't have any books on exceptions (got a lot of other type books ) but I am
currently reading on the net. Doing it right .... well I seriously doubt I am that
far yet, but one this is for sure I am doing it.
Thanks again.
From: Joseph M. Newcomer on 25 Jun 2010 13:02
MFC indeed had exceptions (the TRY/CATCH macros) long before they were in the C++
compiler. Actually, they were defined by the language but Microsoft hadn't implemented
them in the compiler yet (in fact, they were not implemented until many years after they
were in the standard. One of the limitations of that implementation was that there wasn't
a way to have a temporary object, so the objects were allocated on the stack to give them
a duration so that when you got to the catch site, there was still an object.
joe

On Fri, 25 Jun 2010 16:40:13 +0200, Giovanni Dicanio
<giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote:

>On 25/06/2010 13:48, Jeff Flinn wrote:
>
>> The generally accepted approach is to throw by value, which you've done,
>> and catch by [const] ref. This is contrary to most of Microsoft's code,
>> which new's up an exception on the heap and throws the pointer.
>
>This is not "Microsoft's code", it is MFC's code.
>There is also Microsoft's code which correctly throws on the stack (like
>ATL exceptions).
>
>I'm not sure (probably Joe or other long-timers know better), but it
>seems to me that MFC used exceptions before the C++ standard defined
>them and/or the usual C++ patterns matured enough.
>
>Giovanni
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 25 Jun 2010 13:09
See below...
On Fri, 25 Jun 2010 12:31:36 -0400, "RB" <NoMail(a)NoSpam> wrote:

>
>> The generally accepted approach is to throw by value, which you've done,
>> and catch by [const] ref.
>
>Thanks for the reply,
> All of this is enlightening given I did not even know one could return the
>definition of class and have it constructed on the stack.
****
You are not returning the "definition of a class", you are returning an object of that
type. This is how

CString f(...)
{
CString s;
...
return s;
}

works
****
>At first I thought
>it is already on the stack so why reference it, but then I shouldn't have
>equated the stack ownership as any ramification since other items are sometimes
>on the stack also. A reference is a reference I guess, no matter where it references.
***
Actually, it is a *lot* more complex than that, but it is all magic and the magic works.
For example, you cannot pass a pointer (or reference) to a stack variable across thread
boundaries. In fact, C++ is predicated on a single-thread model so cross-thread
much-of-anything is outside the scope of the language. Be careful about this.

If you don't think it is magic, single-step the assembly code of a throw of an object. I
did it once, years ago, and it was quite interesting.
****
>
>> Why would your object ever need to be "fairly large"?
>
>Not sure if it would, I know the one I currently experimenting with certainly
>isn't.
****
It is not clear why "large" matters at all. And I have no idea what "fairly large" means.
> 1024 bytes? > 4096 bytes? > 1Mbytes? When does a structure go from "tiny" to "small" to
"reasonable" to "big" to "massive"?
joe
****
>
>> You might want to get a book and/or google C++ exceptions. To do right, an
>> exception architecture takes thought and effort. Jeff
>
> I don't have any books on exceptions (got a lot of other type books ) but I am
>currently reading on the net. Doing it right .... well I seriously doubt I am that
>far yet, but one this is for sure I am doing it.
>Thanks again.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: How to embed a word document in CView
Next: _ATL_NO_EXCEPTIONS conflict