How about a template class TLazyArray; afterwards?forward declaring the TArray caused a linker error, the other appears to have no effect since TARRAY is used in untemplate.h
removing ENGINE_API adds linker errors to TLazyArray -
The additions with ENGINE_API being removed, or the forward declaration of TArray add these linker errors.
Code: Select all
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TLazyArray::TLazyArray(class TLazyArray const &)" (__imp_??0?$TLazyArray@E@@QAE@ABV0@@Z) 1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TLazyArray::~TLazyArray(void)" (__imp_??1?$TLazyArray@E@@QAE@XZ) 1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TLazyArray::TLazyArray(int)" (__imp_??0?$TLazyArray@E@@QAE@H@Z)
For direct access use https://forums.oldunreal.com
It's been quite a while since oldunreal had an overhaul, but we are moving to another server which require some updates and changes. The biggest change is the migration of our old reliable YaBB forum to phpBB. This system expects you to login with your username and old password known from YaBB.
If you experience any problems there is also the usual "password forgotten" function. Don't forget to clear your browser cache!
If you have any further concerns feel free to contact me: Smirftsch@oldunreal.com
It's been quite a while since oldunreal had an overhaul, but we are moving to another server which require some updates and changes. The biggest change is the migration of our old reliable YaBB forum to phpBB. This system expects you to login with your username and old password known from YaBB.
If you experience any problems there is also the usual "password forgotten" function. Don't forget to clear your browser cache!
If you have any further concerns feel free to contact me: Smirftsch@oldunreal.com
Is there a proper fix for TArray linkage?
- han
- Global Moderator
- Posts: 686
- Joined: Wed Dec 10, 2014 12:38 am
Re: Is there a proper fix for TArray linkage?
- []KAOS[]Casey
- OldUnreal Member
- Posts: 4497
- Joined: Sun Aug 07, 2011 4:22 am
- Location: over there
Re: Is there a proper fix for TArray linkage?
by "typename", I mean
from
to
for a few functions
I did actually end up checking if the .lib exports TArray or BYTE, and it doesn't. SO I think I understand the issue better that my compiler is trying to link to something that's not actually exported, as explained.
And yes, I mean explicit instantiation of TArray
in UnTemplate.h.
So then, its pretty much just a hunt for what has the CORE/ENGINE_API macro at this point, it seems?
from
Code: Select all
TI& Add( TTypeInfo::ConstInitType InKey, TTypeInfo::ConstInitType InValue )
Code: Select all
TI& Add( typename TTypeInfo::ConstInitType InKey, typename TTypeInfo::ConstInitType InValue )
I did actually end up checking if the .lib exports TArray or BYTE, and it doesn't. SO I think I understand the issue better that my compiler is trying to link to something that's not actually exported, as explained.
And yes, I mean explicit instantiation of TArray
in UnTemplate.h.
So then, its pretty much just a hunt for what has the CORE/ENGINE_API macro at this point, it seems?
- Masterkent
- OldUnreal Member
- Posts: 1469
- Joined: Fri Apr 05, 2013 12:41 pm
Re: Is there a proper fix for TArray linkage?
The reason why new VC++ issues an error message in case of the variant without the typename keyword is that it better follows the language rules that require presence of typename in such situations:by "typename", I mean
14.6 Name resolution
When a qualified-id is intended to refer to a type that is not a member of the current instantiation (14.6.2.1) and its nested-name-specifier refers to a dependent type, it shall be prefixed by the keyword typename, forming a typename-specifier.
1.4 Implementation compliance
If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as conditionally-supported when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
Explicit instantiation has nothing common with forward declaration except a similar syntax. The purpose of a forward declaration is to declare an entity (so it could be referenced later in the same translation unit) while the purpose of an explicit instantiation is to manually generate the definition of particular entity from some generic definition (template) parametrized with certain template arguments. In the vast majority of situations, implicit instantiation (which is performed automatically) is sufficient and explicit instantiation is not needed.And yes, I mean explicit instantiation of TArray
in UnTemplate.h.
F.e., here
Code: Select all
#include
template
auto min_value(T1 const &x1, T2 const &x2) ->
decltype(x1 < x2 ? x1 : x2)
{
return x1 < x2 ? x1 : x2;
}
int main()
{
std::cout
Last edited by Masterkent on Fri Sep 09, 2016 12:51 pm, edited 1 time in total.
- []KAOS[]Casey
- OldUnreal Member
- Posts: 4497
- Joined: Sun Aug 07, 2011 4:22 am
- Location: over there
Re: Is there a proper fix for TArray linkage?
Sent you the whole kit&kaboodle for it in PM.
Edit:
Note that SetSize is commented on the TArray because UT99 doesn't have it and I never got around to implementing a workaround for that yet.
Edit:
Note that SetSize is commented on the TArray because UT99 doesn't have it and I never got around to implementing a workaround for that yet.
Last edited by []KAOS[]Casey on Thu Sep 15, 2016 3:06 am, edited 1 time in total.
- han
- Global Moderator
- Posts: 686
- Joined: Wed Dec 10, 2014 12:38 am
Re: Is there a proper fix for TArray linkage?
Actually that fixed it for me (and using the other UnTemplate.h I sent, along the removed ENGINE_API on the FMipmap[Base]), though the changes for FMipmap* might not be necessary.edit2: FSoundData isn't even used in my code so why would changing that be necessary?
Seems like there is some special thing going on with class
Code: Select all
ENGINE_API FSoundData : public TLazyArray
Using a staged approach also removes the link errors:
Code: Select all
//class ENGINE_API FSoundData : public TLazyArray
class TLazyByteArray : public TLazyArray {};
class ENGINE_API FSoundData : public TLazyByteArray
{
public:
USound* Owner;
void Load();
FLOAT GetPeriod();
FSoundData( USound* InOwner )
: Owner( InOwner )
{}
};
- Masterkent
- OldUnreal Member
- Posts: 1469
- Joined: Fri Apr 05, 2013 12:41 pm
Re: Is there a proper fix for TArray linkage?
I don't see any explicit description of the behavior when a dllimport class is derived from a non-dllimport class (for dllexport, MSDN provides some description: https://msdn.microsoft.com/en-us/library/twa2aw10.aspx).
IMO, the best thing you can do here is to remove the dllimport attribute from the entire class FSoundData and add such an attribute to its members that surely have to be imported (if such members exist). If FSoundData::Load and FSoundData::GetPeriod belong to the set of entities that must be imported, the resulting code should look like:
IMO, the best thing you can do here is to remove the dllimport attribute from the entire class FSoundData and add such an attribute to its members that surely have to be imported (if such members exist). If FSoundData::Load and FSoundData::GetPeriod belong to the set of entities that must be imported, the resulting code should look like:
Code: Select all
class FSoundData : public TLazyArray
{
public:
USound* Owner;
ENGINE_API void Load();
ENGINE_API FLOAT GetPeriod();
FSoundData( USound* InOwner )
: Owner( InOwner )
{}
};
Last edited by Masterkent on Thu Sep 15, 2016 3:23 pm, edited 1 time in total.
- han
- Global Moderator
- Posts: 686
- Joined: Wed Dec 10, 2014 12:38 am
Re: Is there a proper fix for TArray linkage?
Yeah, the only vague hint on the issue on that page is:
But they won't state what they actually did change.Because of a change in behavior introduce in Visual C++ .NET to make the application of dllexport more consistent between regular classes and specializations of class templates, if you apply dllexport to a regular class that has a base class that is not marked as dllexport, the compiler will generate C4275.
I agree, and thats actually the solution I came up with last year when trying to get ALAudio building for Nerf. But at least I now know a bit more about what causes the issue.IMO, the best thing you can do here is to remove the dllimport attribute from the entire class FSoundData and add such an attribute to its members that surely have to be imported (if such members exist). If FSoundData::Load and FSoundData::GetPeriod belong to the set of entities that must be imported, the resulting code should look like:
Code: Select all
class FSoundData : public TLazyArray { public: USound* Owner; ENGINE_API void Load(); ENGINE_API FLOAT GetPeriod(); FSoundData( USound* InOwner ) : Owner( InOwner ) {} };
- []KAOS[]Casey
- OldUnreal Member
- Posts: 4497
- Joined: Sun Aug 07, 2011 4:22 am
- Location: over there
Re: Is there a proper fix for TArray linkage?
SetSize worked after I removed CORE_API on FArray. Looks like everything builds properly now, and I can import textures after a few changes to get file loading to work properly.
Thanks a ton to both of you -- hopefully this thread will be useful for someone else in the future too...
It may even revive my multi-map server mod attempt on DeusEx as a way to preserve gamestates between map changes... always wanted to see if that could work. Just couldn't get dot's mod to compile for DX.
Thanks a ton to both of you -- hopefully this thread will be useful for someone else in the future too...
It may even revive my multi-map server mod attempt on DeusEx as a way to preserve gamestates between map changes... always wanted to see if that could work. Just couldn't get dot's mod to compile for DX.
- han
- Global Moderator
- Posts: 686
- Joined: Wed Dec 10, 2014 12:38 am
Re: Is there a proper fix for TArray linkage?
Does it run all maps parallel, where players can be on each of the maps?It may even revive my multi-map server mod attempt on DeusEx as a way to preserve gamestates between map changes... always wanted to see if that could work. Just couldn't get dot's mod to compile for DX.
- []KAOS[]Casey
- OldUnreal Member
- Posts: 4497
- Joined: Sun Aug 07, 2011 4:22 am
- Location: over there
Re: Is there a proper fix for TArray linkage?
yeah, it can. though I would probably want to enforce that only one map runs at a time since the game normally doesn't work like that
- han
- Global Moderator
- Posts: 686
- Joined: Wed Dec 10, 2014 12:38 am
Re: Is there a proper fix for TArray linkage?
Yeah, Deus Ex content would most certainly totally break with players across different maps.yeah, it can. though I would probably want to enforce that only one map runs at a time since the game normally doesn't work like that
However, if you would limit it to one map anyway, what is the point in having some dual server thing anyway? Saving the map while comforming the savefile to the original map file during mapchange works too.
- []KAOS[]Casey
- OldUnreal Member
- Posts: 4497
- Joined: Sun Aug 07, 2011 4:22 am
- Location: over there
Re: Is there a proper fix for TArray linkage?
edit:Oh fuck, I guess you could do that too..
Didn't even think of the conforming at all
Didn't even think of the conforming at all
Last edited by []KAOS[]Casey on Tue Sep 20, 2016 4:44 pm, edited 1 time in total.
- Leo T_C_K
- OldUnreal Member
- Posts: 3673
- Joined: Sat Aug 27, 2005 6:24 pm
Re: Is there a proper fix for TArray linkage?
I did, but in case of maps I was always afraid of glitches resulting from client desync, however the changes in the save files are minimal...
this would even work with the hub system thing left in Unreal, the push and pop/peer system.
this would even work with the hub system thing left in Unreal, the push and pop/peer system.
- han
- Global Moderator
- Posts: 686
- Joined: Wed Dec 10, 2014 12:38 am
Re: Is there a proper fix for TArray linkage?
Well actually I did before.As for compiler [VC6] bugs, I never ran into a single one so far, for uc i did.
Code: Select all
// Load a class object.
template< class T > UClass* LoadClass( UObject* Outer, const TCHAR* Name, const TCHAR* Filename, DWORD LoadFlags, UPackageMap* Sandbox )
{
return UObject::StaticLoadClass( T::StaticClass(), Outer, Name, Filename, LoadFlags, Sandbox );
}
Code: Select all
// Inside a single function.
UClass* ClientClass = LoadClass( [...] );
UClass* RenderClass = LoadClass( [...] );
Code: Select all
UClass* ClientClass = LoadClass( [...] );
UClass* RenderClass = LoadClass( [...] );
So as a workaround one can replace it with a direct StaticLoadClass() call. Eventually commenting this out in the headers to.
Other templates like ConstructObject doesn't seem to be affected, but maybe one shouldn't rely on it.
Last edited by han on Sat Oct 15, 2016 1:51 pm, edited 1 time in total.