this require me to write my C code inside C++ file, that I do not know, and probably I will damage it.

Seems more easy to me, keep separate as much as possible the C++ and C, keeping them in different files.
For example the C++ code generated by QTCreator remain untouched with them methods, and the C algorithm in my hand written files the same. For sure I will add the C++ method invocation to my C part (like a C function call). It is possible?
and then compile both with a C++ compiler.

This let me have more confidence with algorithm file, because I understand error and warning better, as all the file is C syntax but the C++ method invocation only (I do not expect syntax error and problems on QTCreator generated files).
With this solution, the only thing I don't know (apart QT), is how to call a C++ method, the syntax needed (an example of course), taking care that arguments to be passed are variables defined with C syntax, keeping all previous C code intact.
This facilitate the port from a pure CLI C, and also from GTK+ C code.

I suppose will call functions by pointer, and pass variables by pointer (that it is probably what happen to C++ object code when is traslated to C at the start of compilation).

thanks

Hildon-related things (libhildon and its friends) will definitely work on MeeGo.
Work is underway to port them.

wow!!!
;-)

C++ syntax isn't that different from C.
As the C++ part and the C part are for different purpose, separating them is a good idea, like splitting one C program
in different modules.
I wrote the Calendar Home Widget, this is a GTK(hildon) based
widget, just like every other hildon home widget. I use the GTK api,
plain old C datatypes and some C++ objects. But it is actually C++ code and it is compiled with c++.
I had to use this, as the calendar api (calendar-backend) IS a c++ library.
You won't see much difference.
This depends on the type of C++ functions you want to call.

regards
Nicolai

Note that there are no guarantees for hildon implementation, including quality/maintenance; it may not be the smartest way to start developing a new application.

Just for kicks, why won't you just bite the bullet and try it?

One area where C and C++ differ is that if you are using lot's of void pointers, you may need to add a few casts. That's 10 minutes of work.

Hey, I submitted a keynote about this to the Meego Conference this year

see the thread here: http://talk.maemo.org/showthread.php?t=61269

efa:
Use what you think is right. Programming languages aren't that important and if it comes to porting it from one low-level language like C to another low-level language like C++, they're all very similar anyway :-)

SpideyBR said:
>Since C is a subset of C++

No, it isn't anymore. But almost.

> you can design your UI with C++, maybe even with QTCreator or other tool, and then just add your algorithm source and header files and invoke then directly from C++.

True, to a point. C++ function declarations aren't that much different from C function declarations. The naming convention is different, though. And the standard data structures are all different.

>If you have in your C source/headers:
>void do_something(int myint, char *cool_array, float awesomeRate);

efa:
If you mix C and C++ code, you have to add the following stuff to your C header file:

#ifdef __cplusplus
extern "C" {
#endif

void my_function(int x); /* or whatever */

#ifdef __cplusplus
};
#endif

ONLY then you can #include the header file into a C++ source file. This is so it looks the C functions up using the C naming convention.

And only then, :
>You just call them in C++ with:
>do_something(i, charArray, 3.1);

And this isn't the most difficult thing.
The difficult thing is to call a C++ method from within a C function.
If you specify the name of a C++ method, it will pick up only the CODE BLOCK address.
A C++ object instance has the data part (called "this"), without it, you can't call any C++ method that stores data in its object.
So you have to carry around both the code address and the data address and get it in a C callback and once you do that, how is it any different from just using plain C structs in the first place?

And if you are in an C source file, C++ types are not there so you cannot specify the signature of the function to call and since there's no reflection, that would be it. The only practical to get that to work is to compile the "C" code in C++ as well, which technically makes it (really weird) C++ code.

On the other hand, if you specify a callback in a modern language, it will of course automatically carry both the code and the data pointers (and eventual curried arguments).

Note that Qt adds a lot of customizations (they even have their own *callback compiler*) on top of C++ to make it bearable.
The library "Boost" does as well.
However, this is bandaids on top of bandaids and in the end the C++ compiler will use up 500 MB RAM in normal operation and take long to compile anything. And the error messages look like they are from another planet.

SpideyBR said:
>C++ is C with powers, believe it!

C++ makes me despair for computer science.

If I want to have actual fun doing programming, I use Python.

And about the comment about memory management, Glib does reference counting memory management and the GObject system already is an object system. How does it get better than that? Does Qt do garbage collection? Add anything of value to the object system?

As for using Qt because it will be used in upcoming MeeGo devices, that's a valid reason. On the other hand, they have Gtk as well.

As for how C++ is preprocessed to C:

----------------- C++ ----------------------------
class S {
protected:
int m_common;
public:
S();
}; // note semicolon

class A : public S {
private:
bool m_flag;
public:
A();
void checkSomething();
bool getFlag() const;
}; // note semicolon

S::S() {
this->m_common = 42;
}

A::A() {
this->m_flag = false;
}

void A::checkSomething() {
...
this->m_flag = true;
}

bool A::getFlag() const {
return this->m_flag;
}

int main() {
A a;
a.checkSomething();
a.getFlag();

or
A* b = new A;
b->checkSomething();
b->getFlag();
return 0;
}

----------------- C ----------------------------

typedef struct {
int m_common;
} S; // note semicolon

typedef struct {
S super;
bool m_flag;
} A; // note semicolon

void Z1SZ4ctor(S* this) {
this->m_common = 42;
}

void Z1AZ4ctor(A* this) {
Z1SZ4ctor((S*) this);
this->m_flag = FALSE;
}

void Z1AZ14checkSomething(A* this) {
this->m_flag = TRUE;
}

int Z1AZ7getFlagC(A* this) {
return this->m_flag;
}

int main() {
A a;
Z1AZ4ctor(&a); // this is done automatically in C++
Z1AZ14checkSomething(&a);
Z1AZ7getFlagC(&a);

or
A* b = malloc(sizeof(A));
Z1AZ4ctor(b); // this is done automatically in C++ (and in Glib because of g_object_new)
Z1AZ14checkSomething(b);
Z1AZ7getFlagC(b);
return 0;
}
---------------------
Not in the example:
- As I said, C++ method pointers are really really weird, which is why C++ programmers avoid them usually and just hardcode the method calls (like C programmers do except for signals). Qt went out of their way to make them less-sucky by autogenerating code, this is called the Meta-Object compiler (MOC).
- Virtual functions

class A {
public:
A();
virtual void foo();
};

A::A() {
... your code
}

void A::foo() {
}

A a;
a.foo();

is C++-speak for:

struct A {
void (*Z1AZ3foo)(A* this);
};

void Z1AZ4ctor(A* this) {
this->Z1AZ3foo = Z1AZ3foo; // note that this is inserted into the actual constructor of the object where the new method is defined. This means that "foo" can still be NULL in below _even though_ it was defined and a method exists. Fun.
... your code.
}

void Z1AZ3foo(A* this) {
}

A a;
Z1AZ4ctor(&a);
a.Z1AZ3foo(&a); // NOT Z1AZ3foo(&a);

- C++ has exceptions. These are like setjmp() / longjmp(), but you can define automatic code blocks.
- C++ has templates which are like macros.
- the C++ macro language (templates etc) is (barely) turing complete while compiling, which means anything you could do at runtime you also can do at compiletime (note, nobody said it would look in any way readable :-) )
- C++ has namespaces which can be automatically prepended to your names. i.e.
using W = gtk_window;
W::new();

or whatever :-)

You rarely see GObject being considered better than something (/anything) else. Only small set of even Gtk+ programmers are willing to deal with it (and use PyGtk instead).

Well, I think the preference of PyGtk is because of Python.
Of course comparing Python and C&GObject, C&GObject loses. It's like comparing a modern train and a horse carriage.

C++ and C&GObject, not so much. They're very similar, only GObject is more advanced because it came later and learnt from the silly mistakes C++ made (no reflection, no properties (and by that, no automatic notification or monitor pattern), no reference counting, broken virtual methods, making copies all over the place, no Variant datatype, no signals, ...)
Some mistakes they share, like automatically calling the superclass constructor at the beginning of the constructor of this class (as opposed to anywhere in it).
Some mistakes are very special to C++ and nobody would ever replicate:

#include <iostream>

class A {
public:
A();
virtual void foo();
};

class B : public A {
public:
virtual void foo();
};

void A::foo() {
std::cout << "How in the world did I get here?" << std::endl;
}

void B::foo() {
std::cout << "Hello world" << std::endl;
}

A::A() {
this->foo();
}

int main() {
B b;
return 0;
}

*runs it*
"How in the world did I get here?"
*shakes head*

Some mistakes are special to GObject and nobody would ever replicate:

the virtual methods "set_property" and "get_property" should not call their ancestor method (of the superclass).
All other virtual methods should. What gives?

But as I said, with Qt and Boost, C++ is bearable.