C++ Gurus

[quote author="Volker" date="1313088183"]
[quote author="loladiro" date="1313076273"]A pointer is not destroyed at the end of a function. A variable that is created on the stack is.
[/quote]

Sorry for nitpicking here :-)

The pointer actually is destroyed (it is treated like an ordinary variable and it is created on the stack too), it's the object it points to that survives (and that is created on the heap). If you do not save the objects address somewhere else (explicitly or implicitly using e.g. Qt's parent-child-relationship of QObject based classes), that object is lost and can never be accessed again, thus leading to a memory leak.[/quote]

Volker, you're right of course, should have mentioned that. Also, I don't mind nitpicking at all. It is quite useful to get the details right.

@Alicemirror: Yes it is... ;-)

Or just use QtCreator and have it do that for you behind the scenes ;-) I agree it is good to know how to do it by hand too though.

Please be sure and add a [Solved] to the title of your post if it's all taken care of! Thanks!

The C++ standard is very clear about what a default constructor is (section 12.1, number 5):

[quote]
A default constructor for a class X is a constructor of class X that can be called without an argument. If there is no user-declared constructor for class X, a default constructor is implicitly declared. [...]
[/quote]

[quote author="Monkey666" date="1312207879"]There have been many threads ont he internet which have used the following and apparently is supposed to work for finding a process by name:

@
if (stricmp(proc.szExeFile, "test") == 0)
@

However that doesn't work for me, it gives an error about using WCHAR* where it should be CHAR*.

[/quote]

I've already used win32 API (i suppose you too). To solve the problem in Visual studio just set "Character set" within project setting to non unicode and you don't have anymore that problem

And you're lost with anything else than 7 bit ASCII; as soon as other QStrings are involved it's probably converted again and again.

Of course there are use cases for plain const char * constants, but IMO they are very limited.

It's for a reason that ever serious C++ framework has its string classes :-)

Thank you Volker. Yes, I forget to add the const to my code below which is why i got that deprecated warning message.

I will do some more c++ studying.

@char *tt = "test";@

I'll check it out bro, thanks for the help :) And Linux {No Thanks!} lol, my applications are designed for windows users which I generally develop in C#, however I am trying to 'up my game' with C++, but I fear I have let myself in for a world of hurt.

@
return QString('(') + QString::number(ID) + ')' + WindowName.c_str()
@
Also have a look at "More Efficient String Construction":http://doc.qt.nokia.com/latest/qstring.html#more-efficient-string-construction

Hi kalster,

setDisabled is a method of the class QWidget and there fore also for each derived class.
If you are inside the class (so inside the derived classes members) you can directly call it. If you are outside (or want to call it for another object) you have to use the target object as selector:

@
MainWindow w;
w.setDisabled(true);
@

or

@
QCheckBox* pCheck;
pCheck->setDisabled(true);
@

Hi,

by default, QObjects are not copiable, so also not models.
This was also discussed in this forum some times.

Why should any model (you have no idea of the implementation in this code snippet) be copiable to a QStandardItemModel? You try to copy some interface (QAbstractItemModel) to a specific sub class.

It woudl be the same as:

@
class A{
public:
int a;
};

class B : public A{
public:
int b;
int c:
}

class C : public B{
public:
int d;
int e:
}

foo(A* p)
{
C myData=*p; // this would be your line #1
}
@

This can't work as you don't know if p is a C!

Ok, never mind. It must have been another error somewhere in the code, because now the code compiles.

Initially, it said that there was no addWidget(TestPrototype*) method and that the candidate was addWidget(QWidget*). Now, it doesn't complain and compiles successfully.

Thank you, steno! You've been a great help, Mister Guru! ;)

Hi folks,

I have a [hopefully] more specific topic/example to address re: GUI creation/architecture.

DISCLAIMER: I am both relatively new to Qt AND a procedural rather than OO programmer at heart

Let's say my app will use a stacked widget made up four pages (0-3). For the sake of discussion...

Page 0 = full screen video
Page 1 = partial screen video with a text box underneath
Page 2 = grid of buttons
Page 3 = small video + image + text box

Further, pages 2 & 3 both share/use some common elements, let's call them Label1, Label2, Button1, Button2

Each page's widget as well as the common content are in their own class.

My top level GUI class instantiates the common class and passes that pointer to the constructors of the classes for pages 2 & 3.

My challenge right now is the parent-child relationships formed by assigning widgets to layouts or layouts to layouts. For the example described, the common elements Label1, Label2, Button1 and Button2 will be placed the same on page 2 and on page 3. I rashly assumed that I could add these widgets or their layout from the common class to the layout managers on the pages that use them but this seems to not work.

If any of this makes sense, any practical advice would be most appreciated !

Regards,

John

[quote author="Lukas Geyer" date="1311582311"]Just for the records: enums in C++ do not use the enum name for accessing enum values.
(...)
This is why good class design usually requires that the enum name is part of the enum values (as also seen in Qt).
[/quote]

Also note that this is about to "change":http://en.wikipedia.org/wiki/C++0x#Strongly_typed_enumerations in C++0x. There, the enum name does become part of the value name. You could change your second example to this then:

@
class TestClass
{
public:
class enum Error //note the 'class' in front of the enum keyword
{
Internal, //Note that you no longer need the Error postfix
External
};
};

...

TestClass::Error errorVariable = TestClass::Error::Internal; // correct in C++0x
@

@
for(int i=0;i<dim1;i++)
delete[] mtx[i];
delete[] mtx;
@

Your program seems to be correctly linked to the QtGui library from the SDK (4.7.3), therefore I guess you're loading a plugin that is linking against some other 4.7.1 module, causing the crash. Are you using any KDE style or something like that?

(Of course this gets fixed once you force the LD_LIBRARY_PATH, because then the plugin will use the corresponding module from the SDK).

Thank you, I will look into it.

[quote author="ibingow" date="1309876061"]Yes, you're right. But it's strange that my gcc 3.3.1 can compile your example without warning and error. In fact, in your example, we can write UsingFoo like that
[/quote]

I just don't believe you. My code fails with gcc 3.2.2 with the same error messages. It is very unlikely that it failed on 3.2.x, compiled on 3.3.x and failed again on 3.4.x. You must have modified the code or tweaked some compiler switches.