Iterator as a member: Tree/Graph-like structure

[Pl45m4]

@JonB said in Iterator as a member: Tree/Graph-like structure:

I just use an int as the key and pass task->id for that at map insert time

Yeah that makes sense... but my concern is/was that I have some redundancy. MyTask::id = key AND also already stored in MyTask (and accessible via something like value().id)...

Will try it out.

[JonB]

@Pl45m4
You are saving/losing an int for the key. But even another way to use a QMap you have to provide some key to go with a value. If you use Task * as the key that costs a pointer (even if you also store Task * as the value too) which is actually bigger than an int. Plus your QMap actually goes wrong if you go change what the key pointer points to, or the id inside that, if you change the id in the Task your QMap won't rearrange itself!

Many times we do key-value pairs like this. I could be wrong, but when, say, you have a database table with a primary (or unique) key/index I don't think that stores a "pointer to" its value somewhere in the row for its data, I think it copies the value to the index and then keeps that in sync if the row changes.

But if you are happier with the key as a Task * and override the < operator that is fine too.

[Pl45m4]

@Christian-Ehrlicher said in Iterator as a member: Tree/Graph-like structure:

simply replace QMap<MyTask *, whatever> with QMap<Key, whatever> and provide a operator<() for the key (I was wrong above - you don't have to provide a qHash() but a operator <() for a QMap)

struct Key {
  MyTask *task;
  bool operator <(const Key &o) const
  {
    return  task->id < o.task->id;
  }
};

 QMap<Key, something> myMap;

One more thing @Christian-Ehrlicher :
Is there a reason why you picked an extra struct for the Key instead of using the MyTask::operator < directly?

[Christian Ehrlicher]

@Pl45m4 said in Iterator as a member: Tree/Graph-like structure:

instead of using the MyTask::operator < directly?

Because this operator would not be used by a QMap<MyTask*, ...> as you store a pointer, not a value.

[Pl45m4]

@Christian-Ehrlicher

Ah I see, thanks.

[GrecKo]

How many elements would there be in this container?

[JonB]

@GrecKo
:) Unless it's like more than 100, and this is called many times, and the tasks don't take long to run comparatively, I suspect the whole "fast lookup" won't matter much! But maybe still the principle of how you pick up where you left off from.

[Pl45m4]

@GrecKo

Probably 100-200 at max... usually around 50, I would say :)

Sure I could use some inefficient for loop and search/compare each value manually, but a more efficient and cleaner way seems more reasonable to me ;)

[GrecKo]

An "inefficient" simple for loop may very well be the most efficient after all. When you have 50 elements it won't matter much anyway, pick the container with the friendliest API depending on how you plan to access it.

[Pl45m4]

@GrecKo said in Iterator as a member: Tree/Graph-like structure:

pick the container with the friendliest API depending on how you plan to access it.

Still what @Christian-Ehrlicher and @JonB suggested doesn't sound too bad :)
Will definitely try it.

Similar question: Why is QButtonGroup using a QHash-map for its member buttons? :))
I doubt that there ever will be thousands of button widgets in one group :)