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 gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
