http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Multiple inheritance and pointer equivalence - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6ce10e4cd7c07869?hl=en
* I don't have to tell you... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
* Article on possible improvements to C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e46e9b3e07711d05?hl=en
* Why do some code bases don't use exceptions? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/c255001068888229?hl=en
==============================================================================
TOPIC: Multiple inheritance and pointer equivalence
http://groups.google.com/group/comp.lang.c++/t/6ce10e4cd7c07869?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Nov 27 2009 11:15 pm
From: "io_x"
"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4b0f84ec$0$10444$4fafbaef@reader2.news.tin.it...
> #include <stdio.h>
> #include <stdlib.h>
> #define P printf
> #define i8 signed char
>
> class A{
> public:
> A(){ Aarr= (i8*) malloc(1024); }
> virtual ~A()
> {P("~A(); this=%p\n", this);
> free(Aarr);
> Aarr= (i8*) -1;
> }
> i8* Aarr;
> };
>
> class B{
> public:
> B(){ Barr= (i8*) malloc(1024); }
> virtual ~B()
> {P("~B(); this=%p\n", this);
> free(Barr);
> Barr= (i8*) -1;
> }
> i8* Barr;
> };
>
> class C : public A, public B{
> public:
> virtual ~C(){ P("~C(); this=%p\n", this); }
> };
>
> int main(void)
> { C *c = new C;
> A *a = c;
> B *b = c;
>
> if(c->Aarr==0||c->Barr==0)
> {P("No memory\n");
> goto end;
> }
> printf("c: %p; a: %p; b: %p\n", c, a, b);
> end:;
> delete c;
here seems that both each of "delete a" and "delete c"
is like "delete c"
> P("END\n");
> return 0;
> }
>
> ------------------------------------
> c: 00852FD4; a: 00852FD4; b: 00852FDC
> ~C(); this=00852FD4
> ~B(); this=00852FDC
> ~A(); this=00852FD4
> END
>
>> reliably tell that a and b point to the same object, but the simple
>> 'a == b' doesn't work here.
>>
>> Cheers,
>> Danny.
>
>
>
==============================================================================
TOPIC: I don't have to tell you...
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Nov 27 2009 11:09 pm
From: Joshua Maurice
After reading more, I'm still not quite clear on what Howard Beale
want, so I ask again. More clearly: what is wrong with C++, its order
of construction and destruction, and how virtual calls interact.
Let's first presuppose that constructors and destructors themselves
are not broken. Correct me if you think they are.
That leaves us with this heated, and quite unclear, discussion about
which function should be called when you call a virtual function in a
constructor or destructor. I think our options are:
1- Call function on uninitialized (or destroyed) derived class. This
will almost certainly be bad, and not what the programmer intended (or
the programmer is not familiar with the language and good code design,
and the design is bad).
2- What is currently done. It goes to the most derived currently
constructed object.
3- Disallow virtual function calls on objects under construction or
destruction.
I think I like #2 the most, though I can see some utility from #3.
Howard, I still think you are arguing for #1, and I strongly disagree
with that option on my knowledge and years of experience.
==============================================================================
TOPIC: Article on possible improvements to C++
http://groups.google.com/group/comp.lang.c++/t/e46e9b3e07711d05?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Nov 27 2009 11:42 pm
From: Joshua Maurice
On Nov 26, 7:48 pm, paulto
<pauldontspamt...@removeyourself.dontspam.yahoo> wrote:
> dragan wrote:
>
> [snipped]>> Quite a bit of code will you need to properly destroy automatic
> >> objects (which is quite often the required part of "error handling".
> >> If handling of an error does not require stepping way back, that
> >> error can be IMHO renamed to "yet another condition arising at normal
> >> course of given business").
>
> > Another simple answer from moi: RAII. Problem solved. RAII and exceptions
> > are orthogonal concepts. RAII works as good with other error handling
> > strategies as it does with exceptions.
>
> RAII is a great idea but you need something to kick off the destructors.
> It may be an important component of error handling strategy but
> exception or something else is needed to actually kick off object
> destruction if error processing requires changing the context outside of
> normal flow control operation.
>
> >> a robust context-switching mechanism is
> >> needed (longjmp/setjmp, EPOC32/Symbian's "Leaves" with home-made
> >> cleanup stack etc -- you name it).
>
> > I wouldn't call setjmp/longjmp a "context switching mechanism", but I know
> > what you meant. setjmp/longjmp is not an option in C++ because destructors
> > aren't called during "the unwinding" of the "call stack".
>
> Exactly my point. It won't automatically, you will have to hand-craft
> some stupid mechanism like EPOC32/Symbian cleanup stack and never forget
> put your important objects on it.
Uh... I think you missed the boat on this one. I think dragan meant
"return error codes" when he said "other error handling strategies".
(This includes logging the specific error then returning a generic
"failure" error code. It's still returning an error code.) Any other
kind of error handling is extremely exotic.
He meant that RAII works quite well if you use only error return codes
and do not use exceptions, and he is correct. What you do to "kick off
the destructors" is exit the current scope, generally by returning an
error code (or success code, or any kind of returning).
> I am just saying: for error processing
> some mechanism of context-switching is needed (BTW longjmp/setjmp is
> context-switching: the context in this case are the registers including
> instruction pointer or equivalent and stack frame pointers or
> equivalents. In practice, it's not enough as you want application-level
> "unwinding" of automatic objects as you change the stack pointers or
> equivalents; that's why I am saying exceptions are convenient and cheap
> without obvious drawbacks for the purpose (as long as you do not require
> more flexibility in selection of error processing code targets than
> exception give you), library-based cleanup-stack is worse and
> longjms/setjmp is still worse.. )
I might have to disagree. Is "returning an error code" contained in
"context switching"? Returning an error code is a perfectly fine way
to handle errors, and returning an error code is not in the context of
programming what someone would call "context switching".
==============================================================================
TOPIC: Why do some code bases don't use exceptions?
http://groups.google.com/group/comp.lang.c++/t/c255001068888229?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Nov 27 2009 11:48 pm
From: Joshua Maurice
On Nov 20, 8:09 pm, White Wolf <wo...@freemail.hu> wrote:
> Paavo Helde wrote:
> > Regarding Google, maybe they might have banned exceptions because of the
> > run-time overhead (just guessing). Throwing exceptions is notoriously
> > slow, so they should not be used unless something goes very wrong - but
> > for a 24/7 service like Google nothing should go wrong ever, so no need
> > for exceptions, right?
>
> Notoriously slow is a pretty vague statement. Exceptions do not slower
> the speed of the code unless they are thrown. So your choices are: slow
> your happy code (that runs a billion times) by inserting hundreds of if
> statements into it to propagate return codes up the call stack to the
> handler, or make returning 1000 times slower 3 times a day... It is a
> no brainer to me.
Sadly no. That was the intent. However, on half of all of the unix-
like environments available for me to test on, including Solaris, AIX,
HPUX, Linux, and for the common windows platforms, win32, win64,
exceptions add overhead even when not thrown, some worse than others.
Windows, for example, implements C++ exceptions on top of their
structured exception handling, which means that you're paying a
penalty every time you enter a try block. For a particularly contrived
test I once wrote, I got performance slowdowns of up to ~1.5x slower
than the version which used error return codes on one platform.
Not that I'm trying to say use exceptions or don't in this post. Just
understand their practical costs and don't repeat (wishful)
misinformation.
== 2 of 2 ==
Date: Fri, Nov 27 2009 11:53 pm
From: Ian Collins
Joshua Maurice wrote:
> On Nov 20, 8:09 pm, White Wolf <wo...@freemail.hu> wrote:
>> Paavo Helde wrote:
>>> Regarding Google, maybe they might have banned exceptions because of the
>>> run-time overhead (just guessing). Throwing exceptions is notoriously
>>> slow, so they should not be used unless something goes very wrong - but
>>> for a 24/7 service like Google nothing should go wrong ever, so no need
>>> for exceptions, right?
>> Notoriously slow is a pretty vague statement. Exceptions do not slower
>> the speed of the code unless they are thrown. So your choices are: slow
>> your happy code (that runs a billion times) by inserting hundreds of if
>> statements into it to propagate return codes up the call stack to the
>> handler, or make returning 1000 times slower 3 times a day... It is a
>> no brainer to me.
>
> Sadly no. That was the intent. However, on half of all of the unix-
> like environments available for me to test on, including Solaris, AIX,
> HPUX, Linux, and for the common windows platforms, win32, win64,
> exceptions add overhead even when not thrown, some worse than others.
> Windows, for example, implements C++ exceptions on top of their
> structured exception handling, which means that you're paying a
> penalty every time you enter a try block. For a particularly contrived
> test I once wrote, I got performance slowdowns of up to ~1.5x slower
> than the version which used error return codes on one platform.
>
> Not that I'm trying to say use exceptions or don't in this post. Just
> understand their practical costs and don't repeat (wishful)
> misinformation.
How have you measured? All my tests on Solaris with gcc and Sun CC have
shown the normal execution path to be faster with exceptions than
testing return values.
--
Ian Collins
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment