[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: none
From: |
Ingo Ruhnke |
Subject: |
Re: none |
Date: |
07 Jun 2002 19:55:21 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
David Philippi <address@hidden> writes:
> Why? There is one - it's called signal 11. ;-)
> Dereferencing a 0 pointer will yield a segfault with a core dump. If
> you then just use "gdb pingus core", a simple "up" will show you
> where the segfault occured and in case of a 0 pointer it will be
> very easy to recognise what's the reason.
The dummy_ptr<> did IIRC also init the value with zero, instead of
some undefined random value, but your are right, the loss of using
dummy_ptr might be bigger than the gain. Can remember if I ever
catched a bug with them.
> I can live with that, it's just that I tend to oversee the * if it's placed
> direct behind the type and I've never though of multiplication when seeing
> such a declaration.
class CL_Sprite;
int main ()
{
int Sprite = 5;
int my_sprite = 5;
Sprite * my_sprite;
CL_Sprite * my_sprite2;
}
I guess I know why some people say C++ is ugly...
> BTW is there hope of reducing the numbers of shared_ptr<T> ? I'd guess that
> those are one of the main reasons for the long compilation times since
> templates are awfully slow to compile and boost uses quite every feature of
> templates.
Yep, most or all of them could be replaced by normal pointers if the
structure how and where the 'new' takes place is changed.
--
Advent: http://www.freesoftware.fsf.org/advent/
Feuerkraft: http://www.freesoftware.fsf.org/feuerkraft/
Pingus: http://pingus.seul.org/ || ICQ: 59461927
Home: http://pingus.seul.org/~grumbel/ || JabberID: address@hidden