[Kommander-devel] Questions for seasoned C++ gurus

[Eric Laffoon]

On Tuesday 01 April 2008 12:41:21 pm Andras Mantia wrote:
> Hi,
>
> On Tuesday 01 April 2008, Eric Laffoon wrote:
> > Hi All,
> > I'm rewriting the database plugin for my immediate production use as
> > a more robust and flexible tool, and to make a path to port to KDE4.
>
> Good idea.

I thought so. Next would be:
1) create a query object that you can register field<->widget connctions with. 
Then if you are browsing it will populate the widget accordingly. If it is a 
non text widget it will allow for definitions for combo or checkbox or 
whatever... special instructions so to say. If it is in update or insert mode 
it will take date from the widget and process the query.
2) create a custom data combo widget from parts of a combobox and a 
tablegrid... this will be cool.
3) Create a custom data grid which can manage similar functions to the Knoda 
grid but will be intelligent about query connections with our plugin
4) enable query objects to be set as subqueries to a parent query obect with a 
given key

Possibly it may be easier to create a few more data widgets than query 
handling routines, but I think after the custom widgets only checkboxes and 
radiobuttons need be dealt with as everything else uses straightforward text 
interfaces.
>
> > private:
> >   QSqlDatabase* db;
> >   QSqlQuery* query;
>
> I checked out the code and tries to compile. I think the base problem is
> that you programmed too much in php and too little in C++.

LOL

> "QSqlDatabase * db" means  "db" is a pointer to a QSqlDatabase object
> and should be allocated on the heap with "new" (or with a method that
> returns " QSqlDatabase* "). You can access the methods with
> db->methodname().

So...
db = new QSqlDatabase()
is that right?
You know PHP has that too right? ;-)
>
> QSqlDatabase db on the other hand creates the db object right away at
> that place (so usually you need QSqlDatabase
> db(arguments_of_the_constructor) ) and as this isn't a pointer, you
> access the methods with:
> db.methodname().

Which I got used to doing getting my feet wet. It's not like I can't discern 
the differences. It's just easier to read than remember what to write.
>
> This was the main problem, mixing pointers and none-pointers.
>
> Now if you get an error like:
> /data/development/sources/kommander-
> plugins/database3/src/database.cpp:228: error: passing 'const QSqlQuery'
> as 'this' argument of 'virtual bool QSqlQuery::next()' discards
> qualifiers
>
> it usually means you are treating some const variable as none-const (or
> vice versa), or you access none-const variables from const methods. Here
> that is the problem.

This is something I need to get more comfortable with. I understand what a 
const is, and I can see where it can be useful, but considering exactly where 
problems like accidentally overwriting a variable are still less than 
comfortable. So I tend to think const for passing variables to examine or 
produce output is a good safety measure.
>
> One other thing I noticed was that even though you had a
> QSqlDatabase * db member variable, when you assigned a value to it, you
> declared again. That means that the value was assigned to a local db
> pointer => crash in all other places where you use db->something.

Argh!
>
> So should I fix these issues or will you? ;)
>
> Andras
Actually I need to do some work and get some customers taken care of to get 
some money. A good plan I think, so if you don't mind doing the fixes so it 
compiles I'll look at the code, learn and then being debugging it.

I'm also going to build KDE4 tonight and start looking at porting. Did you 
port what I did in Kommander or leave it for me?

BTW did you try the QtActionProxy? If you request geometry for a widget 
named "dump" it dumps the object tree. ;) I thought it was cool that I was 
able to implement a hasFocus and geometry functions in a proxy. I understand 
that it is not a good idea to save the tree and it would be inefficient to 
make calling it part of every routine, but for limited use to add rarely used  
functionality across widgets I think it is not without interest.


-- 
Eric Laffoon
Project Lead - kdewebdev module