eezstreet Posted August 30, 2013 Posted August 30, 2013 K, so here's the rub. I'm trying to essentially turn cgDC/uiInfo.uiDC into a namespace, as opposed to being a giant glob of function pointers.The definition for the namespace functions is held in ui_devicecontext.cpp, which is included by both cgame and game. The namespace is declared within ui_devicecontext.h, which is included by all the files which make use of the namespace. Here's the code: http://slexy.org/raw/s209ji5Xoe Anyway...yeah, the problem is that the linker barfs over this. Error 4 error LNK2005: "bool (__cdecl* DisplayContext::FeederSelection)(float,int,struct itemDef_s *)" (?FeederSelection@DisplayContext@@3P6A_NMHPAUitemDef_s@@@ZA) already defined in ui_atoms.obj E:\Code Projects\Github\JKGDevs\OpenJK\codemp\ui\ui_devicecontext.obj Error 48 error LNK2005: "bool (__cdecl* DisplayContext::FeederSelection)(float,int,struct itemDef_s *)" (?FeederSelection@DisplayContext@@3P6A_NMHPAUitemDef_s@@@ZA) already defined in ui_atoms.obj E:\Code Projects\Github\JKGDevs\OpenJK\codemp\ui\ui_main.obj Error 92 error LNK2005: "bool (__cdecl* DisplayContext::FeederSelection)(float,int,struct itemDef_s *)" (?FeederSelection@DisplayContext@@3P6A_NMHPAUitemDef_s@@@ZA) already defined in ui_atoms.obj E:\Code Projects\Github\JKGDevs\OpenJK\codemp\ui\ui_saber.obj ad nauseum for each function call btw, I'm calling them like this: DisplayContext::FeederSelection(blah, blah, blah);
Raz0r Posted August 30, 2013 Posted August 30, 2013 Line 370 of that paste is declaring DC_FeederSelection with a different type. Line 208 is also lols. DisplayContext::DisplayContext::
Xycaleth Posted August 30, 2013 Posted August 30, 2013 Generally you should wrap the source file in namespace DisplayContext { } as well like you do in the header file. It's not common (and therefore confusing) to define namespaced functions like you do there.
eezstreet Posted August 30, 2013 Author Posted August 30, 2013 Generally you should wrap the source file in namespace DisplayContext { } as well like you do in the header file. It's not common (and therefore confusing) to define namespaced functions like you do there.Makes no difference either way on the linking errors.
Xycaleth Posted August 30, 2013 Posted August 30, 2013 Sure, it was general advice. Raz0r's post should fix the problem?
eezstreet Posted August 31, 2013 Author Posted August 31, 2013 Will try Raz0r's fix as soon as I can. Thanks for the assist.
eezstreet Posted September 2, 2013 Author Posted September 2, 2013 Fixed. Apparently I had to: a) define the variable objects (xscale, etc) in the .cpp file B) extern said variable objects in the .hc) #pragma once the .cpp file (probably not necessary at all come to think of it, but I just ran with it)
Xycaleth Posted September 2, 2013 Posted September 2, 2013 Pragma once in a .cpp file won't do anything
Futuza Posted September 6, 2013 Posted September 6, 2013 ^^ for header files, also I prefer #ifndef's, but pragma once works too.
eezstreet Posted September 7, 2013 Author Posted September 7, 2013 Pragma once in a .cpp file won't do anything Yea, that was mostly for test purposes, I didn't think it would really do anything (then again, Raven includes .cpp files, so anything is possible!). Just being extra cautious. ^^ for header files, also I prefer #ifndef's, but pragma once works too.#ifndef header guards are gcc compatible, therefore compliant with unix. #pragma once is MSVC-specific. Like I said though, that was mostly for test purposes and will be removed at some point.
eezstreet Posted September 7, 2013 Author Posted September 7, 2013 Got another one for you... Game crashes due to an assertion failure: Assertion Failed!vector iterators not compatible Checking the lines, it's in SV_Baseline, right at the end: sv.svEntities[entnum].baseline = svent->s; The confusing part of this is that they're the exact same damn type, so how could the vector contained within be of a different iterator type? Confusing. Hitting ignore on the assertion leads to another one, which says something along the lines of "C++ standard library undefined behavior", hitting it again results in a "jkgalaxies.x86.exe has tripped a fatal error", which I noted as having odd text compared to the regular unhandled exceptions.
Xycaleth Posted September 7, 2013 Posted September 7, 2013 This means you're using iterators from different vectors and trying to compare them or use them in the same operation, so I doubt it's that line that's causing the problem
eezstreet Posted September 7, 2013 Author Posted September 7, 2013 Right. As I've noted, it's ps->inventory/s->inventory causing problems. They're both of type Inventory. class Inventory { private: std::vector<InventoryItemInstance*> items; } I think one possible solution to this problem would be to overload the = operator and properly copy the vectors (instead of them apparently having different iterators, which makes no sense at all because they're exactly the same type). I think technically speaking this is one way to reproduce it: std::vector<int> blah; std::vector<int> blah2; ... blah2 = blah;
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now