pygccxml-development

[pygccxml-development] Current Vector Indexing Suite

[Lakin W. <lak...@gm...>]

In order to handle the situation of a class that is missing operator==, but
is being exported using the current vector indexing suite, I wrote something
which writes code similar to:

inline bool operator==(::Ogre::CompositorInstance::TargetOperation lhs,
::Ogre::CompositorInstance::TargetOperation rhs) {
    throw std::runtime_error("::Ogre::CompositorInstance::TargetOperation
has no comparison operator.");
}

for each class.  This file is then included in the pyplusplus generated
code.  From my understanding of C++, this should be enough.  However, I
still get the same compiler error.  If I add the appropriate member function
directly to class' header file, the generated code compiles.

What am I missing?

Lakin

Re: [pygccxml-development] Current Vector Indexing Suite

[Roman Y. <rom...@gm...>]

On 6/24/06, Lakin Wecker <lak...@gm...> wrote:
> In order to handle the situation of a class that is missing operator==, but
> is being exported using the current vector indexing suite, I wrote something
> which writes code similar to:
>
> inline bool
> operator==(::Ogre::CompositorInstance::TargetOperation lhs,
> ::Ogre::CompositorInstance::TargetOperation rhs) {
>     throw
> std::runtime_error("::Ogre::CompositorInstance::TargetOperation
> has no comparison operator.");
> }
>
> for each class.  This file is then included in the pyplusplus generated
> code.  From my understanding of C++, this should be enough.  However, I
> still get the same compiler error.  If I add the appropriate member function
> directly to class' header file, the generated code compiles.
>
> What am I missing?

I think scope. Compiler does not look for operator== where you think
it looks for.
I am afraid, that for classes that defined within other classes you don't have
solution. ( I hope somebody will say that I am wrong and show the solution ).
For classes that defined in the namespace, you can define operator==
in that namespace.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Current Vector Indexing Suite

[Lakin W. <lak...@gm...>]

I asked around in the #C++ channel on irc.freenode.net, and found out that
you are right. It is scope issues, however you can still define the operator
in the namespace(like you suggested) and it will find it appropriately, even
for nested classes.  For my case I simply wrap them in
namespace Ogre {
        inline bool operator==(::Ogre::CompositorInstance::TargetOperation
const &lhs, ::Ogre::CompositorInstance::TargetOperation const &rhs) {
            throw
std::runtime_error("::Ogre::CompositorInstance::TargetOperation has no
comparison operator, using contains has no meaning.");
        }
}

and it begins to compile.  Perhaps we can do the same thing in pyplusplus.
In my mind, there are two issues.

1)  if we don't issue a warning about it, users may be unsuspecting about
the error, so we should still issue a warning when running pyplusplus.
Additionally, maybe we can issue the same warning via a compiler directive
such as #warning for g++?  Of course, all of these warnings should be
disabled via the option that we previously discussed on the mailing list.
2) We should still provide a way to completely disable the indexing suite (I
think this is already done?)

In my mind, an exception thrown is an appropriate pythonic way of handling
this.  An exception would also be thrown if the __contains__ method was not
provided for a pythonic list-like object.

Lakin

On 6/24/06, Roman Yakovenko <rom...@gm...> wrote:
>
> On 6/24/06, Lakin Wecker <lak...@gm...> wrote:
> > In order to handle the situation of a class that is missing operator==,
> but
> > is being exported using the current vector indexing suite, I wrote
> something
> > which writes code similar to:
> >
> > inline bool
> > operator==(::Ogre::CompositorInstance::TargetOperation lhs,
> > ::Ogre::CompositorInstance::TargetOperation rhs) {
> >     throw
> > std::runtime_error("::Ogre::CompositorInstance::TargetOperation
> > has no comparison operator.");
> > }
> >
> > for each class.  This file is then included in the pyplusplus generated
> > code.  From my understanding of C++, this should be enough.  However, I
> > still get the same compiler error.  If I add the appropriate member
> function
> > directly to class' header file, the generated code compiles.
> >
> > What am I missing?
>
> I think scope. Compiler does not look for operator== where you think
> it looks for.
> I am afraid, that for classes that defined within other classes you don't
> have
> solution. ( I hope somebody will say that I am wrong and show the solution
> ).
> For classes that defined in the namespace, you can define operator==
> in that namespace.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] Current Vector Indexing Suite

[Roman Y. <rom...@gm...>]

On 6/24/06, Lakin Wecker <lak...@gm...> wrote:
> I asked around in the #C++ channel on irc.freenode.net, and found out that
> you are right. It is scope issues, however you can still define the operator
> in the namespace(like you suggested) and it will find it appropriately, even
> for nested classes.  For my case I simply wrap them in
> namespace Ogre {
>         inline bool
> operator==(::Ogre::CompositorInstance::TargetOperation
> const &lhs, ::Ogre::CompositorInstance::TargetOperation
> const &rhs) {
>             throw
> std::runtime_error("::Ogre::CompositorInstance::TargetOperation
> has no comparison operator, using contains has no meaning.");
>         }
> }
>
> and it begins to compile.

:-). I am glad I was wrong!

> Perhaps we can do the same thing in pyplusplus.
> In my mind, there are two issues.
>
> 1)  if we don't issue a warning about it,

py++ writes the warning in the generated code.

> users may be unsuspecting about
> the error, so we should still issue a warning when running pyplusplus.

This still should be done!

> Additionally, maybe we can issue the same warning via a compiler directive
> such as #warning for g++?  Of course, all of these warnings should be
> disabled via the option that we previously discussed on the mailing list.

I will check boost. I am sure they have such functionality, that works on all
compilers.

> 2) We should still provide a way to completely disable the indexing suite (I
> think this is already done?)

Yes

mb.build_code_creators( ..., enable_indexing_suite=False )

> In my mind, an exception thrown is an appropriate pythonic way of handling
> this.  An exception would also be thrown if the __contains__ method was not
> provided for a pythonic list-like object.

It seems that you are right. I am not sure whether I want to fix this or not.
I spent my time learning new indexing suite. It will take only few hours to
implement it, really. A lot of functionality is already there.



-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/