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

Is there a proper fix for TArray linkage?

User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Is there a proper fix for TArray linkage?

Post by han »

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)
How about a template class TLazyArray; afterwards?
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]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?

Post by []KAOS[]Casey »

by "typename", I mean

from

Code: Select all

TI& Add( TTypeInfo::ConstInitType InKey, TTypeInfo::ConstInitType InValue )
to

Code: Select all

TI& Add( typename TTypeInfo::ConstInitType InKey, typename TTypeInfo::ConstInitType InValue )
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?
User avatar
Masterkent
OldUnreal Member
Posts: 1469
Joined: Fri Apr 05, 2013 12:41 pm

Re: Is there a proper fix for TArray linkage?

Post by Masterkent »

by "typename", I mean
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:
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.
And yes, I mean explicit instantiation of TArray
in UnTemplate.h.
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.

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.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Is there a proper fix for TArray linkage?

Post by han »

Okay, I'm back at home, if you sent me the msvc2013 stuff which caused these build errors I can test my luck with them. :)
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]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?

Post by []KAOS[]Casey »

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.
Last edited by []KAOS[]Casey on Thu Sep 15, 2016 3:06 am, edited 1 time in total.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Is there a proper fix for TArray linkage?

Post by han »

edit2: FSoundData isn't even used in my code so why would changing that be necessary?
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.

Seems like there is some special thing going on with class

Code: Select all

ENGINE_API FSoundData : public TLazyArray
when the specializations happens as part of deriving from that template rather then using it as some (member) variable, while it gets exported at the same time.

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 )
      {}
};
Maybe MK can shed some light onto this.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
Masterkent
OldUnreal Member
Posts: 1469
Joined: Fri Apr 05, 2013 12:41 pm

Re: Is there a proper fix for TArray linkage?

Post by Masterkent »

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:

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.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Is there a proper fix for TArray linkage?

Post by han »

Yeah, the only vague hint on the issue on that page is:
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.
But they won't state what they actually did change.

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 )
      {}
};
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.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]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?

Post by []KAOS[]Casey »

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.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Is there a proper fix for TArray linkage?

Post by han »

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.
Does it run all maps parallel, where players can be on each of the maps?
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]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?

Post by []KAOS[]Casey »

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
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Is there a proper fix for TArray linkage?

Post by han »

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
Yeah, Deus Ex content would most certainly totally break with players across different maps.

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.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]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?

Post by []KAOS[]Casey »

edit:Oh fuck, I guess you could do that too..


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.
User avatar
Leo T_C_K
OldUnreal Member
Posts: 3660
Joined: Sat Aug 27, 2005 6:24 pm

Re: Is there a proper fix for TArray linkage?

Post by Leo T_C_K »

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.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Is there a proper fix for TArray linkage?

Post by han »

As for compiler [VC6] bugs, I never ran into a single one so far, for uc i did.
Well actually I did before.

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( [...] );
When compiled under VC6 this translates in my case to:

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.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
Post Reply

Return to “C++ Native Mods for UE1”