prepare_create_table wrapping - part2

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

prepare_create_table wrapping - part2

Pavlo Solntsev-2
hi,
I found some mistakes in my code and fixed them. However, I can't
figure out where is the problem. I included new patch for my changes as
well as log from the compiler. Could someone take a look?
Thanks.


--
- Pavlo Solntsev
---------------------------------------------
Sent from Evolution on GNU/Debian <www.debian.org> id="-x-evo-
selection-start-marker">


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list

prepare_create_table.patch (2K) Download Attachment
create_table_gcc.log (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Kjell Ahlstedt-2
Den 2017-05-09 kl. 05:18, skrev Pavlo Solntsev:
> hi,
> I found some mistakes in my code and fixed them. However, I can't
> figure out where is the problem. I included new patch for my changes as
> well as log from the compiler. Could someone take a look?
> Thanks.
>
>
The description of gda_server_operation_prepare_create_table() says that
the "arguments" parameter is a list of GdaServerOperationCreateTableArg,
but if you look at the code in gda-server-operation.c, you'll see that
it's really a list of GdaServerOperationCreateTableArg*, i.e. a list of
pointers. GdaServerOperationCreateTableArg is defined in
gda-server-operation.c, hidden from your code. You must use a
std::vector<GdaServerOperationCreateTableArg*>.

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Pavlo Solntsev-2
Dear Kjell.

I tried your suggestions and some problems are gone. However, I see
some type conversion issue. It looks like
_GdaServerOperationCreateTableArg type is not visible. I tried using
RefPtr instead of plain pointers - same effect. I attached g++ output
and patch. Thanks for any comments.




On Tue, 2017-05-09 at 19:05 +0200, Kjell Ahlstedt wrote:

> Den 2017-05-09 kl. 05:18, skrev Pavlo Solntsev:
> > hi,
> > I found some mistakes in my code and fixed them. However, I can't
> > figure out where is the problem. I included new patch for my
> > changes as
> > well as log from the compiler. Could someone take a look?
> > Thanks.
> >
> >
>
> The description of gda_server_operation_prepare_create_table() says
> that 
> the "arguments" parameter is a list of
> GdaServerOperationCreateTableArg, 
> but if you look at the code in gda-server-operation.c, you'll see
> that 
> it's really a list of GdaServerOperationCreateTableArg*, i.e. a list
> of 
> pointers. GdaServerOperationCreateTableArg is defined in 
> gda-server-operation.c, hidden from your code. You must use a 
> std::vector<GdaServerOperationCreateTableArg*>.
>
--
- Pavlo Solntsev
---------------------------------------------
Sent from Evolution on GNU/Debian <www.debian.org> id="-x-evo-
selection-start-marker">


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list

prepare_create_table.patch (4K) Download Attachment
libgdamm_pavlo.log (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Kjell Ahlstedt-2

Glib::ListHandler uses a type traits class. It's a second template argument with a default value. The default type traits class is not suitable for your case, even though it might be considered the most elementary case: Convert a std::vector<T*> to GList with T* elements.

First decide if you will use GdaServerOperationCreateTableArg pointers directly in libgdamm, or if you want to to wrap them in a Gda::ServerOperationCreateTableArg class. Then make a type traits class suitable for either std::vector<GdaServerOperationCreateTableArg*> or std::vector<Gda::ServerOperationCreateTableArg>. You can find some examples of type traits classes in glibmm/gio/src/resolver.ccg, gtkmm/gtk/src/iconview.hg, gtkmm/gtk/src/papersize.hg.

RefPtr is not useful here. It contains a pointer to a C++ object with reference() and unreference() methods.

Den 2017-05-09 kl. 21:19, skrev Pavlo Solntsev:
Dear Kjell.

I tried your suggestions and some problems are gone. However, I see
some type conversion issue. It looks like
_GdaServerOperationCreateTableArg type is not visible. I tried using
RefPtr instead of plain pointers - same effect. I attached g++ output
and patch. Thanks for any comments. 




On Tue, 2017-05-09 at 19:05 +0200, Kjell Ahlstedt wrote:
Den 2017-05-09 kl. 05:18, skrev Pavlo Solntsev:
hi,
I found some mistakes in my code and fixed them. However, I can't
figure out where is the problem. I included new patch for my
changes as
well as log from the compiler. Could someone take a look?
Thanks.


The description of gda_server_operation_prepare_create_table() says
that 
the "arguments" parameter is a list of
GdaServerOperationCreateTableArg, 
but if you look at the code in gda-server-operation.c, you'll see
that 
it's really a list of GdaServerOperationCreateTableArg*, i.e. a list
of 
pointers. GdaServerOperationCreateTableArg is defined in 
gda-server-operation.c, hidden from your code. You must use a 
std::vector<GdaServerOperationCreateTableArg*>.



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Pavlo Solntsev-2
Dear Kjell.

My initial idea was to wrap struct GdaServerOperationCreateTableArg as a class inside the Gda::ServerOperatio. It should look like: Gda::ServerOperation::CreateTableArg. To do so I used _CLASS_GENERIC macros. I wasn't successful. It may be implemented manually, but in that case, it will not be wrap. I see not option now how to transform C-style struct to C++ class. I am talking about struct to class conversion because in C API there are a set of functions that can logically be wrapped as methods for C++ class. However, simple macros will not give enough flexibility for expansion the class. Do you think it is a good idea to write a class from scratch (without using macroses) based on C API? I may try this route but I want to make sure it is not against *mm rules of porting. 

I will play with your suggestion. 

Thanks,

-Pavlo Solntsev


On Thu, May 11, 2017 at 6:20 AM, Kjell Ahlstedt <[hidden email]> wrote:

Glib::ListHandler uses a type traits class. It's a second template argument with a default value. The default type traits class is not suitable for your case, even though it might be considered the most elementary case: Convert a std::vector<T*> to GList with T* elements.

First decide if you will use GdaServerOperationCreateTableArg pointers directly in libgdamm, or if you want to to wrap them in a Gda::ServerOperationCreateTableArg class. Then make a type traits class suitable for either std::vector<GdaServerOperationCreateTableArg*> or std::vector<Gda::ServerOperationCreateTableArg>. You can find some examples of type traits classes in glibmm/gio/src/resolver.ccg, gtkmm/gtk/src/iconview.hg, gtkmm/gtk/src/papersize.hg.

RefPtr is not useful here. It contains a pointer to a C++ object with reference() and unreference() methods.

Den 2017-05-09 kl. 21:19, skrev Pavlo Solntsev:
Dear Kjell.

I tried your suggestions and some problems are gone. However, I see
some type conversion issue. It looks like
_GdaServerOperationCreateTableArg type is not visible. I tried using
RefPtr instead of plain pointers - same effect. I attached g++ output
and patch. Thanks for any comments. 




On Tue, 2017-05-09 at 19:05 +0200, Kjell Ahlstedt wrote:
Den 2017-05-09 kl. 05:18, skrev Pavlo Solntsev:
hi,
I found some mistakes in my code and fixed them. However, I can't
figure out where is the problem. I included new patch for my
changes as
well as log from the compiler. Could someone take a look?
Thanks.


The description of gda_server_operation_prepare_create_table() says
that 
the "arguments" parameter is a list of
GdaServerOperationCreateTableArg, 
but if you look at the code in gda-server-operation.c, you'll see
that 
it's really a list of GdaServerOperationCreateTableArg*, i.e. a list
of 
pointers. GdaServerOperationCreateTableArg is defined in 
gda-server-operation.c, hidden from your code. You must use a 
std::vector<GdaServerOperationCreateTableArg*>.




_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Kjell Ahlstedt-2

I don't think it's possible to use _CLASS_GENERIC or any of the other _CLASS_* macros in a class within another class.


Den 2017-05-11 kl. 15:21, skrev Pavlo Solntsev:
Dear Kjell.

My initial idea was to wrap struct GdaServerOperationCreateTableArg as a class inside the Gda::ServerOperatio. It should look like: Gda::ServerOperation::CreateTableArg. To do so I used _CLASS_GENERIC macros. I wasn't successful. It may be implemented manually, but in that case, it will not be wrap. I see not option now how to transform C-style struct to C++ class. I am talking about struct to class conversion because in C API there are a set of functions that can logically be wrapped as methods for C++ class. However, simple macros will not give enough flexibility for expansion the class. Do you think it is a good idea to write a class from scratch (without using macroses) based on C API? I may try this route but I want to make sure it is not against *mm rules of porting. 

I will play with your suggestion. 

Thanks,

-Pavlo Solntsev




_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Pavlo Solntsev-2
ok, good to know. I will try to build a class inside ServerOperation. What I found, traits class needs a copy constructor for CppType method. I don't see a simple way to overcome this just by using:
typedef GdaServerOperationCreateTableArg CreateTableArg

and traits class.

Probably a full class should be built. Thanks.


-Pavlo Solntsev


On Fri, May 12, 2017 at 6:32 AM, Kjell Ahlstedt <[hidden email]> wrote:

I don't think it's possible to use _CLASS_GENERIC or any of the other _CLASS_* macros in a class within another class.


Den 2017-05-11 kl. 15:21, skrev Pavlo Solntsev:
Dear Kjell.

My initial idea was to wrap struct GdaServerOperationCreateTableArg as a class inside the Gda::ServerOperatio. It should look like: Gda::ServerOperation::CreateTableArg. To do so I used _CLASS_GENERIC macros. I wasn't successful. It may be implemented manually, but in that case, it will not be wrap. I see not option now how to transform C-style struct to C++ class. I am talking about struct to class conversion because in C API there are a set of functions that can logically be wrapped as methods for C++ class. However, simple macros will not give enough flexibility for expansion the class. Do you think it is a good idea to write a class from scratch (without using macroses) based on C API? I may try this route but I want to make sure it is not against *mm rules of porting. 

I will play with your suggestion. 

Thanks,

-Pavlo Solntsev





_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Kjell Ahlstedt-2
In reply to this post by Kjell Ahlstedt-2
You have misspelt CreateTableArgTraits in some places
(CreateTableArgTriats), but not everywhere.

You can remove the CONVERSION()s to Glib::RefPtr<const
ServerOperationCreateTableArg> and
Glib::RefPtr<ServerOperationCreateTableArg>. I suppose they are not
used, and therefore make no harm.

There may be other errors, I haven't studied your code in detail.


Den 2017-05-13 kl. 05:45, skrev Pavlo Solntsev:

> ok,
> I implemented my CreateTableArgTriats struct similar to the given
> example. I also added CreateTableArg class but without all methods.
> Now, I have incomplete class CreateTableArg
>
> In file included from /home/pavlo/jhbuild/install/include/glibmm-
> 2.54/glibmm.h:142:0,
>                   from
> /home/pavlo/jhbuild/checkout/libgdamm/libgda/libgdamm/serveroperation.c
> c:4:
> /home/pavlo/jhbuild/install/include/glibmm-2.54/glibmm/vectorutils.h:
> In instantiation of ‘class
> Glib::ListHandler<Gnome::Gda::ServerOperation::CreateTableArg,
> Gnome::Gda::CreateTableArgTriats>’:
> /home/pavlo/jhbuild/checkout/libgdamm/libgda/libgdamm/serveroperation.c
> c:100:72:   required from here
> /home/pavlo/jhbuild/install/include/glibmm-
> 2.54/glibmm/vectorutils.h:533:35: error: invalid use of incomplete type
> ‘class Gnome::Gda::CreateTableArgTriats’
>     using CType = typename Tr::CType;
>                                     ^
> and also
> /home/pavlo/jhbuild/install/include/glibmm-
> 2.54/glibmm/vectorutils.h:859:27: error: incomplete type
> ‘Gnome::Gda::CreateTableArgTriats’ used in nested name specifier
>           Tr::release_c_type(static_cast<CTypeNonConst>(node->data));
>           ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> What did I miss?
>
>
>

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Kjell Ahlstedt-2
This discussion is perhaps more suitable for a bug report. But if you
had started with a libgdamm bug, I would not have found it. Anyway, here
are some comments.

_WRAP_METHOD and many other _WRAP_* macros can only be used in a class
with a _CLASS_* macro. In this patch it looks like
ServerOperationCreateTableArg is not included within another class. It
ought to be possible to use one of the _CLASS_* macros, perhaps
_CLASS_OPAQUE_COPYABLE.

cnc.operator->()->gobj()? Why not just cnc->gobj()?

Don't ServerOperationCreateTableArg's copy constructors leak memory?
They assign to _parent several times.


Den 2017-05-13 kl. 18:42, skrev Pavlo Solntsev:

> Dear Kjell.
>
> Thank you so much for pointing on that. I have successfully compiled
> libgdamm. Could you please take a look for CreateTableArg class
> implementation. Is it something we can stay with? I found that
> _WRAP_METHOD doesn't work in this case.
>    
> Thanks.
>
>
> On Sat, 2017-05-13 at 09:53 +0200, Kjell Ahlstedt wrote:
>> You have misspelt CreateTableArgTraits in some places
>> (CreateTableArgTriats), but not everywhere.
>>
>> You can remove the CONVERSION()s to Glib::RefPtr<const
>> ServerOperationCreateTableArg> and
>> Glib::RefPtr<ServerOperationCreateTableArg>. I suppose they are not
>> used, and therefore make no harm.
>>
>> There may be other errors, I haven't studied your code in detail.
>>
>>
>> --
> - Pavlo Solntsev
>

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: prepare_create_table wrapping - part2

Pavlo Solntsev-2
Dear Kjell.

There is no open bug. I should probably explain how it started. I have
personal interests in using libgdamm. I found that simple process of
creating tables was missed in libgdamm. However, in libgda those
methods were available. I had two options: 1) make my own version of
methods to create a table or 2) help community and add those methods to
libgdamm. Initial problem with implementation was with understanding
how implementation (wrapping) works. Sorry, but not a lot of
documentation available. I naturally expected different behavior of
_CLASS_GENERIC methods and _WRAP_METHOD. In the process I learn
information that wasn't clearly available to me: class in class
wrapping. Wrapping non GObject based classes etc. To all that, I didn't
know internal policy in *mm projects. Does it make sense to write
classes in the mm module? How to wrap correctly C style struct to C++
class, or leave it as a struct. After I spent some time, played with
code, bugged you (sorry for that) I have already answers for majority
of the listed above questions but some of them still unclear.

I will file a bug report for missing
Gda::ServerOperation::prepare_create_table()
Gda::ServerOperation::perform_create_table()
methods to track all changes.

And I agree with you comments.

Best,

On Sun, 2017-05-14 at 19:28 +0200, Kjell Ahlstedt wrote:

> This discussion is perhaps more suitable for a bug report. But if
> you 
> had started with a libgdamm bug, I would not have found it. Anyway,
> here 
> are some comments.
>
> _WRAP_METHOD and many other _WRAP_* macros can only be used in a
> class 
> with a _CLASS_* macro. In this patch it looks like 
> ServerOperationCreateTableArg is not included within another class.
> It 
> ought to be possible to use one of the _CLASS_* macros, perhaps 
> _CLASS_OPAQUE_COPYABLE.
>
> cnc.operator->()->gobj()? Why not just cnc->gobj()?
>
> Don't ServerOperationCreateTableArg's copy constructors leak memory? 
> They assign to _parent several times.
>
>
> Den 2017-05-13 kl. 18:42, skrev Pavlo Solntsev:
> > Dear Kjell.
> >
> > Thank you so much for pointing on that. I have successfully
> > compiled
> > libgdamm. Could you please take a look for CreateTableArg class
> > implementation. Is it something we can stay with? I found that
> > _WRAP_METHOD doesn't work in this case.
> >    
> > Thanks.
> >
> >
> > On Sat, 2017-05-13 at 09:53 +0200, Kjell Ahlstedt wrote:
> > > You have misspelt CreateTableArgTraits in some places
> > > (CreateTableArgTriats), but not everywhere.
> > >
> > > You can remove the CONVERSION()s to Glib::RefPtr<const
> > > ServerOperationCreateTableArg> and
> > > Glib::RefPtr<ServerOperationCreateTableArg>. I suppose they are
> > > not
> > > used, and therefore make no harm.
> > >
> > > There may be other errors, I haven't studied your code in detail.
> > >
> > >
> > > -- 
> >
> > - Pavlo Solntsev
> >
>
>
--
- Pavlo Solntsev
---------------------------------------------
Sent from Evolution on GNU/Debian <www.debian.org> id="-x-evo-
selection-start-marker">


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Loading...