C++ Gurus

Thank you. It's ok now.

Hi,

first of all, I moved it to the C++ forum, as it's more a generic problem then a Qt problem.

I assume, you cxall the function with a string and then (outside the function) the string is not changed, right?

Zhis comes due to the fact, that cou call the function with a copy of your string you want to change. If you want to modify the original string, you need a pointer or a reference:

@
void Convert(QString& givenphonenum)
{
}
@

The second problem you have, is that the string might be shorter then 100 chars. Try out the following:

@
void Convert(QString& givenphonenum)
{
for (int i = 0; i < givenphonenum.length(); i++)
{
}
}
@

Ok, thanks to help.

[quote author="Lukas Geyer" date="1322068030"]I'm not quite sure if I understand your last post correctly, but if it is about just storing a bunch of data then I see no sense in using anything other than char* (or whatever alignment you prefer).[/quote]

And again sorry for my English :).
QByteArray has a couple of useful features, and also has the ability to access data through operator []. As Andre said, 10k is easy for QByteArray.
For my case it's enough.

[quote author="Gerolf" date="1322056043"][quote author="qxoz" date="1322045941"]And it's called maximum 10 times per sec.[/quote]

Don't care about speed optimization, care about maintainability then :-)
[/quote]

I will. Thank you.

Copying a QString is indeed a fast operation, just copying a pointer and incrementing a counter. However, not copying is going to be even faster, of course.

It's not relevant to Qt but you should add another declaration of friendFunction() before definition of class A.

[quote author="nokiaadict" date="1320878701"]by using your examples you could use
@
int arrayLength = sizeof(array) / sizeof(int); //if you array is comprised of int values
for(int i=arrayLength; i > 0;i--) array[i] = array[i-1];
@
[/quote]

Be very careful when making loop to go backwars with arrays. In this example, the first access is probably going to overflow the array. There are two basic ways to go through the array:

Forward:

[code]for(int i=0; i < length; i++) { ...}[/code]

Backward:

[code]if(length > 0) for(int i=length; i--;) { ... }[/code]

Doing other than those needs always deeper analysis of the loop. If the direction does not matter, always go forward, it makes it much easier to understand to any other programmer.

EDIT: In the example, the trick is (very common) "scrolling" (moving) the array, in which case you don't go through the whole array, but array length -1. There are common solutions for both forward (as in this case) and backwards "scrolling".

My pleasure. Thanks redirected to zchyderm and girish for authoring the said articles. :)

[quote author="deimos" date="1319910499"]this has nothing to do with int and long ?
can you try with:

bq. vec.reserve(1000000000L);[/quote]

Actually, no. QVector (and all other container classes) only work with integers (int, not long or long long). So, I guess it is just outside of the Qt containers specs to try to strore that many items in one. I would recommend using a different container class for that, from outside of Qt.

[edit: answer put outside quote, Eddy]

Check out "QProcess":http://developer.qt.nokia.com/doc/qt-4.7/qprocess.html to run arbitrary commands. Note that running external commands can be tricky when you try to do something on several platforms: The commands tend to have different names and different behaviors on all the different OSes out there.

thank you for your answers.

@Lukas,indeed the line 23 was ok.The error was in some other part of my code

This can be done in an easy way:

@
class MyWidget : public QWidget{
MyWidget(QList<TableViewHandler*>& _handlers, QWidget* parent);
...
QList<TableViewHandler*> handlers;
};

MyWidget::MyWidget(QList<TableViewHandler*>& _handlers, QWidget* parent):
QWidget(parent),
handlers(_handlers) // <-- here, the data is copied
{
}

//+++++++++++++++++++++++++++++++++++++++++++++++++++

foo()
{
QList<TableViewHandler*> handlers;
// initialize the list
...
MyWidget* w = new MyWidget( handlers ); // here, a reference is given to the constructor, as the parameter
// is a reference, but it will be copied behind the scenes, so the
// automatic deletion on method end is ok.
...
}
@

As QList is an implicitly shared class, the copy will be cheap as it only copies a simple pointer to the contained data and the deletion of the stack object will not really delete the data, only decrease the ref count and everything is safe. Thanks to the implicitly shared classes, it's cheap and easy...

Thank you for your friendly post, Volker.
I will take a close look at these FAQs, I have a lot to learn...
Now, you might be, the case being, interested in Dr Agner Fog' s
manual about C++ optimization (from a programmer viewpoint,
it' s not about compiler writing).
I encourage everyone to visit his great website http://www.agner.org/.
You will find there various manuals and (free) software packages.
This man has an incredible knowledge of microprocessor architectures
and assembly language optimization. I owe him so much.

Cheers.

Thanks, using the QAction* works for me!

[quote]You’ve created a reference to variable which immediately goes out of scope, creating an invalid reference.[/quote]

I know. I did it on purpose. Just to show that references give no additional guarantees in that sense, compared to pointers (both can be "invalid"/"dangling"). Another example:

@
int main() {
int *a = new int(42);
int &r = *a;
delete a;
// oops! r is invalid now
}
@

That's because you said:
[quote]The primary difference between a reference and a pointer is a reference gives certain guarantees, namely that it corresponds to something, that that something is valid, and that it will be valid for the lifetime of that reference. An invalid reference is bad, most compilers will happily compile that (with a warning or two) and your application will behave badly.[/quote]

Which, again: makes no sense. You can't say that references give the guarantee that it refers to something "valid" throughout its entire lifetime, because it's false. In fact you then say that invalid references can exist. So that's not what references do actually guarantee.

The primary differences between a reference and a pointer are:

references can't be reseated references don't have "special" values (NULL)

That's all.

[quote]In terms of correct code, if you have a null reference, you have a bug. So yes, references are always valid in correct C++. If you like writing software riddled with segmentation faults, be my guest, just don’t peddle it as anything but garbage. Just because something compiles, doesn’t mean it will run (Do I really need to tell you this?), it’s no mean feat to write garbage code that will compile and fault when run.[/quote]

Of course. I was referring to your statement above. Obviously that's a bug (exactly like a dangling pointer, although I should check the standard to find out if the only fact of having invalid references leads to UB).

[quote]how about you go and have a look at some of the badly evolved C89 libraries, and tell me how great they are to work with?[/quote]

Oh, doing Xlib programming is absolutely great :-D

[quote]
Oh, and as for your opinion (or rather, that of Mr Cline), if you’d looked beyond your nose, you would have seen this:

@
// What does it mean that a reference must refer to an object, not a dereferenced NULL pointer?
// It means this is illegal:

T* p = NULL;
T& r = p; ← illegal
T p = NULL;
T& r = *p; ← illegal
@
[/quote]

The problem with that snippet, in my humble opinion, has little to do with references -- you're dereferencing the NULL pointer, and that's undefined behaviour in C/C++ (even before thinking of initializing a reference to whatever *p returns).

[quote]The statement that good, modern C++ doesn’t require an advanced understanding of templates is absolutely ridiculous, and out of step with the direction of the language of the last 2 decades. Boost, the standard library and Qt all use templates, and at some point, someone had to master them.[/quote]

I totally agree; but luckily people managed to write very solid code by using Qt and avoiding to mess up with highly templated (and possibly unreadable) code. I don't consider using QList<Foo> "understanding" templates in any way (which is unfortunate -- knowing what you're doing is always a good thing).

So, can we consider this argument settled down? :)

@
MyClass::MyClass(QWidget parent = 0)
:QTreeView(parent)
@

sorry about this, I just copy paste the same code on the hurry, I did not compile it mentally before posting... :D

this one compiles

@
MyClass::MyClass(QWidget parent)
:QTreeView(parent)
@

Absolutely right!