Geometry Boost List: [ggl] space partitioning

Subject: [ggl] space partitioning
From: Duzy Chan (duzy)
Date: 2010-09-12 06:18:02

On Sun, Sep 12, 2010 at 1:50 AM, Hartmut Kaiser <hartmut.kaiser_at_[hidden]>wrote:

> > On Fri, Sep 10, 2010 at 9:11 PM, Hartmut Kaiser <
> hartmut.kaiser_at_[hidden]>
> > wrote:
> > > Since all these examples uses EMPTY classes, codes as following will
> > > complaint nothing and event run as people expects -- the tree::foo()
> > > will be invoked:
> > >
> > > struct tree : public node
> > > {
> > >    void foo()
> > >    {
> > >        do_something_with_node(static_cast<node*>(this));
> > >    }
> > >    /* no atributes */
> > > }
> > >
> > > internal_node *in = new internal_node(); tree *t =
> > > static_cast<tree*>(static_cast<node*>(in));
> > > t->foo();
> > >
> > > As a member function needs a object pointer to be invoked, in facts,
> > > it's not matter what's the pointer really pointed to, if your  class
> > > hierarchy is empty classes, no CRASH will complaint. But if you try to
> > > insert some member fields in 'tree', and intend to access any fields,
> > > the whole world will CRASH -- the 'this' pointer is in fact pointed to
> > > something totally different.
> > Even with empty classes it's still undefined behavior, so all bets are
> > off.
> >
> > Still undefined of cause, unless people uses virtual on 'foo()'. In fact
> > examples like that tree-node-foo is nothing object oriented, that empty-
> > class trick is just a strange thing in object oriented, hides real object
> > type to C++, and cause more strange things happened while doing typeinfo
> > on that 'this' pointer of tree. Think of the following segment:
> >
> > #include <iostream>
> > #include <typeinfo>
> >
> > struct base
> > {
> > };
> >
> > struct derived : base
> > {
> >   void blah() { std::cout<<"derived"<<std::endl; }
> >   void pointer_type() { std::cout<<typeid(this).name()<<std::endl; }
> >   void object_type() { std::cout<<typeid(*this).name()<<std::endl; } };
> >
> > int main()
> > {
> >   base obj;
> >   base *o = &obj;
> >   derived *p = (derived*)o;
> >   p->blah();
> >   p->pointer_type();
> >   p->object_type();
> > }
> >
> > Well the typeid operator is in fact static binded, so people may gains
> > output as one expected, but we all knows that the C++ compiler has been
> > tricked. How to make C++ compiler smarter? And how could C++ people be
> > more aware of the real type without so many virtuals?
>
> Well, I'm certainly not sure what you're aiming at here, but if you want to
> avoid virtual functions, templates are still your friend. Everything you can
> do with virtual functions at runtime can be done with templates at compile
> time.
>
>
As a C++ people, I'm just pointing out things that maybe not right but still
goes in reality and see how people will have points on these, thus we all
learns from it, I will prefer to see bads than goods about C++ and see the
solves people will have.

As the compile time calculation, I see how we can program the program, which
give us really great ability to program better, but on the other side, C++
compiler nowadays 'execute' the program's program slow, maybe very slow for
large scale projects. In fact I like to use meta program always, but I have
to give up sometimes for my productions because of time.

Hopes that the C++1x will come out soon and give us better meta programming
everywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20100912/6e4798d6/attachment.html