Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MagmaMcFry]

If you want to stick with maps, you could use a std::multimap, and use the node as the key.

And that wouldn't even make sense, because I only stick nodes in the priority queue twice because it would take too long to find the first copy of the node again.

[Skyrunner]

gradients

I thought of that, too, but I have too many ports. Something like 150.

priority_queue

Yeah, think I always remove the node to inspect it anyways, so it won't matter greatly.

[MagmaMcFry]

priority_queue

Yeah, think I always remove the node to inspect it anyways, so it won't matter greatly.

No, the priority_queue is the openset, and if you remove and inspect one, it goes into the closedset. And if you inspect a node, you don't update its own f_value, but the f_values of the neighboring nodes.

[Mego]

My eyes have been looking at this project too long. I can't find the source of the undefined reference errors. Help, please.

Also I know I'm probably doing everything in the worst way possible, but my goal is to get something *working* first, and I have a roadmap for that.

[MagmaMcFry]

My eyes have been looking at this project too long. I can't find the source of the undefined reference errors. Help, please.

Also I know I'm probably doing everything in the worst way possible, but my goal is to get something *working* first, and I have a roadmap for that.

Can I have an errorlog please?

[Mego]

It's on my clipboard. I forgot to add it to the post. /me facepalms

Code: [Select]

/tmp/ccqxHCBt.o: In function `ZN3Foo7objnameEv':
/home/Mego/Reflect/main.cpp:10: undefined reference to `Reflect::Member<std::string>::getdata() const'
/tmp/ccYFiwQc.o: In function `ZN7Reflect11ReflectBaseC2ESs':
/home/Mego/Reflect/ReflectBase.cpp:6: undefined reference to `Reflect::Member<std::string>::Member(std::string, Reflect::ReflectBase*, std::string)'
/home/Mego/Reflect/ReflectBase.cpp:6: undefined reference to `Reflect::Member<std::string>::~Member()'
/tmp/ccYFiwQc.o: In function `ZN7Reflect11ReflectBaseD2Ev':
/home/Mego/Reflect/ReflectBase.cpp:12: undefined reference to `Reflect::Member<std::string>::getdata() const'
/home/Mego/Reflect/ReflectBase.cpp:11: undefined reference to `Reflect::Member<std::string>::~Member()'
/home/Mego/Reflect/ReflectBase.cpp:11: undefined reference to `Reflect::Member<std::string>::~Member()'
/tmp/ccYFiwQc.o: In function `ZNK7Reflect11ReflectBase7objnameEv':
/home/Mego/Reflect/ReflectBase.cpp:16: undefined reference to `Reflect::Member<std::string>::getdata() const'
collect2: error: ld returned 1 exit status


[olemars]

Template function definitions in a cpp file, probably. Noone told you templates are Satan's offspring?

[Skyrunner]

Magma: Okay then, missed your edit. So if I should use a heap, would make_heap suffice, on a vector? In that case, how would I cross reference it to a map without having to remake the whole heap each time...? References definitely will break, while iterators could break.

[MagmaMcFry]

Magma: Okay then, missed your edit. So if I should use a heap, would make_heap suffice, on a vector? In that case, how would I cross reference it to a map without having to remake the whole heap each time...? References definitely will break, while iterators could break.

If you want to cross-reference the heap with a map, you'd need a full-featured heap with map coordinates as data keys and the f_value as priority, and you'd need to synchronize the heap with a map that stores the heap index of every node in the corresponding node field, which means that every addKey(), siftUp() or popFirst() operation on the heap needs to update the map as well. You'd need to write the entire data structure from scratch.

This would allow you to quickly (O(1) quickly) find an element in a heap and update its f_value, but given the nature of your data, it seems that this is actually not really worth the effort. What I'd suggest you do instead (and this is probably even faster than the other method) is just store all your f_values in a heap<pair<f_value, coordinates> > with the possibility of duplicate entries. You'll need a map<coordinates, f_value> to avoid putting too many duplicates of nodes into the heap (you only want to add to the heap when your f_value is a new minimum), and a map<coordinates, bool> to flag a node as belonging to the closed_set when you first pull it out of the heap, which allows you to ignore all further occurrences of the node in the heap.

[Mego]

Template function definitions in a cpp file, probably. Noone told you templates are Satan's offspring?

I made a pact in order for this to work, so that shouldn't be an issue. What's wrong with template function definitions in a cpp file that could cause undefined reference errors?

[Skyrunner]

Magma: Okay then, missed your edit. So if I should use a heap, would make_heap suffice, on a vector? In that case, how would I cross reference it to a map without having to remake the whole heap each time...? References definitely will break, while iterators could break.

If you want to cross-reference the heap with a map, you'd need a full-featured heap with map coordinates as data keys and the f_value as priority, and you'd need to synchronize the heap with a map that stores the heap index of every node in the corresponding node field, which means that every addKey(), siftUp() or popFirst() operation on the heap needs to update the map as well. You'd need to write the entire data structure from scratch.

This would allow you to quickly (O(1) quickly) find an element in a heap and update its f_value, but given the nature of your data, it seems that this is actually not really worth the effort. What I'd suggest you do instead (and this is probably even faster than the other method) is just store all your f_values in a heap<pair<f_value, coordinates> > with the possibility of duplicate entries. You'll need a map<coordinates, f_value> to avoid putting too many duplicates of nodes into the heap (you only want to add to the heap when your f_value is a new minimum), and a map<coordinates, bool> to flag a node as belonging to the closed_set when you first pull it out of the heap, which allows you to ignore all further occurrences of the node in the heap.

This data structure thingy sounds out of my league. D: Not only do I not know how to code a heap from scratch, I also don't know the rationale for those choices you outlined...

I think I need to think about this a bit. =~=

[gigaraptor487]

if anybody is interested in a game jam there is a week long one in august on gamedev.net

http://www.gamedev.net/topic/645699-upcoming-unofficial-gamedev-competition/

[olemars]

Template function definitions in a cpp file, probably. Noone told you templates are Satan's offspring?

I made a pact in order for this to work, so that shouldn't be an issue. What's wrong with template function definitions in a cpp file that could cause undefined reference errors?

Template functions are generated as needed per compilation unit (based on the template function definition), and you include the header so the places which would trigger the template can't actually see the template definition. I've seen various workarounds for this, most of them causing tears of blood like including the cpp instead of/as well as the header. The lesser evil is to move the definitions to the header.

edt: Explained in a vitriolic manner here. Read it, all of it. Especially 35.13.

[Nadaka]

I have an idea for a program/game/sim that no one has done before as far as I can tell. No amount of googling has shown even a single prior reference for something even remotely like it. As this may be my very first truly original idea that I can capitalize on... i wont be sharing it until it can be demo'd.

[GlyphGryph]

Not publically, maybe. But I'd recommend sharing it with SOMEONE you trust before going through all the work of a demo.