strange problem passing a vector

[mickey]

Hello,
doesn't anyone have an idea why code (#post1) doesn't work???

thanks...

[wysota]

I'd begin with the notice, that a construction like "xxx*&" seems... weird... but ok...

How did you declare and create "tree"?

[Gopala Krishna]

Everything seems alright, pretty weird error indeed.

Also one minor thing i noticed was tree object wasn't declared but i think that part was trimmed before posting here.

Is the tree code in separate files ? Do have a look if there are any overloaded members that might be interfering.
Also if possible can you post the complete code ?

[mickey]

I'm sorry but I had change it in the second manner (vector<Node>**) and now I try to change into original version to see the error:now it works. Could be a temporary .net problem (restart it I mean) ???
I found the "*&" in Thinking in c++; why doesn't it "ok"? Does have any sense all or it shuold be better in main() declare vecNode on the stack instead on heap?
thanks
(if problem arise again I update post)

[Gopala Krishna]

I'm sorry but I had change it in the second manner (vector<Node>**) and now I try to change into original version to see the error:now it works. Could be a temporary .net problem (restart it I mean) ???
I found the "*&" in Thinking in c++; why doesn't it "ok"? Does have any sense all or it shuold be better in main() declare vecNode on the stack instead on heap?
thanks
(if problem arise again I update post)

*& idiom is used to pass the pointer as reference. That is the pointer passed from the caller is also modified. This is usually used to return multiple values allocated on heap. I think it is ok to use it.
Usually it is better to declare elements on stack rather that heap but it does depend on how you use it in you application.

Here is a small example i tried to assert my assumption.

void create(int *t)
{
     t = new int(2);
}
 
void createRef(int *&t)
{
    t = new int(2);
}
 
int main()
{
    int *h, *k;
    h = k = 0;
    create(h);
    Q_ASSERT(h != 0); // fails
    createRef(k);
    Q_ASSERT(k != 0); // succeeds.
    return 0;
}

void create(int *t)
{
     t = new int(2);
}

void createRef(int *&t)
{
    t = new int(2);
}

int main()
{
    int *h, *k;
    h = k = 0;
    create(h);
    Q_ASSERT(h != 0); // fails
    createRef(k);
    Q_ASSERT(k != 0); // succeeds.
    return 0;
}

To copy to clipboard, switch view to plain text mode 

[wysota]

I think that if you have a method that returns void, passing a reference to a pointer to return something from the method doesn't make much sense - it's better to use a more... traditional approach. But in the above situation it doesn't make sense to pass a reference to a pointer.

[Gopala Krishna]

I think that if you have a method that returns void, passing a reference to a pointer to return something from the method doesn't make much sense - it's better to use a more... traditional approach. But in the above situation it doesn't make sense to pass a reference to a pointer.

Yes, but may be you can use them in helper functions like this.. It saves function calls as well as neatly modularizes the code. Ofcourse it is not conventional.

void createResources(int *&handle, SomeResource *&s, Pen *& pen)
{
}

[wysota]

Yes, maybe... But I wouldn't. Try maintaining such code... Besides, in most cases you'd pass a reference to an object, not to its pointer.

[mickey]

Usually it is better to declare elements on stack rather that heap but it does depend on how you use it in you application.
[/CODE]

What do you mean? What's the reason lead me to allocate the vecNode(in the main) in on the stack or on heap?

[Gopala Krishna]

What do you mean? What's the reason lead me to allocate the vecNode(in the main) in on the stack or on heap?

I mean dont create the vecNode using new. that is, dont use

vector<Node> *listNode = new vector<Node>;

vector<Node> *listNode = new vector<Node>;

To copy to clipboard, switch view to plain text mode 

Instead use

vector<Node> listNode;

vector<Node> listNode;

To copy to clipboard, switch view to plain text mode 

This removes explicit new and delete operations and simplifies code in many places. Ofcourse this is not mandatory, you might find the first solution suitable in your case.

@Wysota: Yeah, that is the reason i told it is unconventional. But it is not "unmaintainable" - atleast in a group of experienced c++ programmers.

[mickey]

Ofcourse this is not mandatory, you might find the first solution suitable in your case.

when can it be suitable? Any examples? (for me there's no difference)...

[Gopala Krishna]

when can it be suitable? Any examples? (for me there's no difference)...

It might be usable when you have to share one vector amongst many instances of same or different objects. Instead of holding many copies you will be holding pointers to vectors.

But you may note that qt's collection classes are implicitly shared and are more easier to use than stl classes. stl classes are powerful only if you know how to extract maximum from them. Otherwise qt's collection classes should suffice for most cases.