[pygccxml-development] problem with private classes

[Gordon W. <gor...@gm...>]

I think I found another bug, but I'm not sure who's bug it is. This:

class Alpha
{
private:
  class Omega
  {
    <snip>
  }

public:
  Omega *pOmega;
}

produces:

static ::Alpha::Omega * get_pOmega(Alpha const & inst ){
  return inst.pOmega;
}

which leads to:

extending.cpp(634) : error C2248: 'Alpha::Omega' : cannot access private
class declared in class 'Alpha'
        c:\program
files\boost\boost_1_35_0\libs\python\example\bobit.h(1458) : see declaration
of 'Alpha::Omega'
        c:\program
files\boost\boost_1_35_0\libs\python\example\bobit.h(1223) : see declaration
of 'Alpha'

On Tue, Jul 8, 2008 at 11:47 AM, Gordon Wrigley <gor...@gm...>
wrote:

> This is about the size right? If so is it going to complain about every
> pointer variable I have? and if that is the case then why doesn't it just
> produce a warning and then assume that if it's not null then the length is
> 1, that at least will work for regular pointers.
> Or is this just about the combination of the pointer and the array?
>
>
> On Tue, Jul 8, 2008 at 11:31 AM, Gordon Wrigley <gor...@gm...>
> wrote:
>
>> OK, that seems to make some sense, but leads to a few lil feature
>> requests.
>>
>> First the py++ code on that page is overly verbose, it would be nice if
>> this could be handled in one line. So for this C++ code:
>>
>> class tom
>> {
>> public:
>>   double *data;
>>   double dataLen;
>>
>> you might have something like:
>>
>> mb.class_( "tom" ).variable( "data" ).size("tom.dataLen")
>>
>> I realise it's probably not going to be quite that simple, I'm just trying
>> to convey the direction of the idea. Also if you had a standard policy of
>> always having a xLen variable for every x pointer variable (or xLen function
>> for every function returning a pointer) then it'd be nice to be able to
>> capture that in a single line.
>>
>> And of course this would all have to be extended somehow to work with my
>> array of pointers example and the documentations width*heigh example.
>>
>> Also that warning that py++ should give when it runs into one of these
>> should include an example of the sort of line required to fix it.
>>
>> :)
>>
>> Gordon.
>>
>>
>> On Mon, Jul 7, 2008 at 6:51 PM, Roman Yakovenko <
>> rom...@gm...> wrote:
>>
>>> On Mon, Jul 7, 2008 at 10:28 AM, Gordon Wrigley
>>> <gor...@gm...> wrote:
>>> > Disclaimer: I have no idea what I'm doing and C++ is not one of my
>>> strong
>>> > skills. I'm having a problem with py++, boost, msvc and a third party
>>> > library I need to bridge to python. I would greatly appreciate any help
>>> I
>>> > can get with this.
>>>
>>> :-)
>>>
>>> > I don't have the various version information handy but I downloaded all
>>> of
>>> > the boost/py++/msvc stuff from the relevant websites last week. After I
>>> > installed everything I made it compile and run the quick start example
>>> > correctly.
>>> >
>>> > I ran the library header through the py++ gui, grabbed the py++ code
>>> that
>>> > generated, put it in a .py file, ran that and then copied the resulting
>>> > files into the quick start example.
>>> >
>>> > The header for the library includes this snippet (details obscured to
>>> > protect the guilty):
>>> >
>>> > class bob
>>> > {
>>> > public:
>>> >     double      *fred[4];
>>>
>>> This is a bug in Py++.
>>>
>>> The code generated for "double* fred[4]" caused the compilation error.
>>> It is not possible to generate code for "fred" without knowing
>>> additional details. In this case Py++ has to exclude this variable
>>> from being exposed and give some warning.
>>>
>>> Now, how can you improve the situation:
>>> * exclude variable by your own
>>> * take a look on "return_range" (
>>>
>>> http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#return-range
>>> ) call policies.
>>>
>>> HTH
>>>
>>> --
>>> Roman Yakovenko
>>> C++ Python language binding
>>> http://www.language-binding.net/
>>>
>>
>>
>