UE1 doesn't use the STL stuff or any newer C++ additions, and you loose all integration into the UE1 framework when using std::vector. So what are in your opinion the shortcommings of TArray?  Also because it wont use templates as much you dont run into the issues msvc6 has with templates, etc.

As for the optimizations, I do a lot of benchmarking on the rendering stuff, and the first non neglectable performance improvement turned out to be for acos, but in this case the advantage is just temporary as weighting face normals is regardlesd of the compiler too expansive at runtime on the cpu, and once this ends up in a compute shader, the perfhingsorman e advantage again vanishes.

Don't get me wrong, for anything new I would  not use MSVC6, but imho for my work on UE1 games it is imho the best solution.

han wrote on Sep 7^th, 2016 at 10:00pm:

A part of program, that does not directly invoke UE functions, may store its data in any suitable containers and use libraries that have no any relationship to UE.

Quote:

It imposes specific requirements on data types which can be used as element types: zero-initialization of object's memory must be sufficient for its default construction, bitwise copy of object's memory must be sufficient for moving the object to a new memory location. Attempts to insert or relocate objects that do not satisfy these requirements may lead to appearance of objects with invalid internal state. std::vector is free of such issues, because it uses value-initialization (that invokes default constructor for objects having a non-trivial default ctor) instead of dumb filling memory with zero bytes for the purposes of default construction, and it uses high-level copy/move operation (that may invoke object's copy/move constructor) in order to relocate an element, so in any case an element can correctly manage its internal state. Also you have to be careful with TArray::SetSize - it may lead to memory leaks, because it does not invoke destructors when the given function is supposed to remove some elements (in case if new size is less than the initial size). IIRC, 227i UScript dynamic arrays of strings had huge memory leaks when performing array downsizing, and it's not hard to guess where that error comes from.

[]KAOS[]Casey wrote on Sep 8^th, 2016 at 4:13am:

Some (not mentioned) linker errors after some (not mentioned) changes in program... M-m-m, OK, good luck with fixing.

Except I did remove those. And the linker errors are one of the many mentioned already here, so I thought it was unnecessary to even paste them

edit: this is the untemplate.h that I was given www.oldunreal.com/cgi-bin/nopaste/?19

Previously I just used 227i public headers untemplate.h

Pretty much just going with the default plan of VC6, because unless we can fenagle the compiler to use the symbols to match what the .lib has, no amount of crappity smacking around will fix it.


edit2: FSoundData isn't even used in my code so why would changing that be necessary?

han wrote on Sep 8^th, 2016 at 2:05pm:

I have no idea what you're implementing there, but I can imagine a mod that would implement some sort of database in C++, and the only part that would really do something with UE functions/classes would be the interface of queries to that database. Implementation of the database itself can be completely independent from UE.

han wrote on Sep 8^th, 2016 at 6:41pm:

That shouldn't be necessary after removal of the dllimport specifier. The compiler should implicitly instantiate everything that needs instantiation unless you either explicitly suppress such instantiation or hide the templated definition of a function from the compiler:

Quote:

Quote:

[]KAOS[]Casey wrote on Sep 9^th, 2016 at 12:45am:

What do you mean by forward declaring the TArray<TCHAR>? The language rules forbid declarations like

class TArray<TCHAR>; 

You can forward-declare the entire template

template <class T>
    class TArray; 

but not its specializations.

If you're referring to explicit instantiation of TArray<TCHAR>

template class TArray<TCHAR>; 

then it could make sense only in DLL that is supposed to export member functions of TArray<TCHAR> that can later might be imported by other module.

When you tell the compiler that some function shall be imported from a DLL, you obviously need to ensure that some DLL really exports such a function. Otherwise, where should the linker obtain that function from?

Since it is impossible to export the entire template, you can export only a finite set of functions that can be generated from the template. The presence of generic definition of a member function like TArray::Remove won't magically make all its possible specializations exported. You can instantiate TArray with billions of types - TArray<char>, TArray<short>, TArray<MyClass1>, TArray<MyClass2>, ..., TArray<MyClass100500>, and so on, and every such a specialization TArray<BlaBlaBla> will have its own distinct member function TArray<BlaBlaBla>::Remove. Hence we have a reasonable question: what set of functions should be exported? Obviously, the compiler needs some hint regarding what set of functions we need.

However, all these things with exporting/importing may be unnecessary (you should know better the specifics of the UE API, because you were working with it; I'm just speaking about the general theory - templates & DLLs). Then you could remove dllimport specifiers and rely on implicit instantiation of templates from headers.

Quote:

These messages clearly indicate that dllimport specifier is present and applied. The linker could previously omit issuance of these errors after detection of other errors.

Quote:

What is a typename declaration?

Quote:

The same history - the compiler sees that TArray<unsigned char>::operator() is odr-used, but does not instantiate the function definition from what you have in your header because of dllimport specifier. The linker fails to find the given function in any DLL and issues an error message.

[]KAOS[]Casey wrote on Sep 9^th, 2016 at 12:45am:

How about a template class TLazyArray<TCHAR>; afterwards?

[]KAOS[]Casey wrote on Sep 9^th, 2016 at 8:16am:

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:

Quote:

Quote:


[]KAOS[]Casey wrote on Sep 9^th, 2016 at 8:16am:

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

#include <iostream>

template <class T1, class T2>
    auto min_value(T1 const &x1, T2 const &x2) ->
        decltype(x1 < x2 ? x1 : x2)
{
    return x1 < x2 ? x1 : x2;
}

int main()
{
    std::cout << min_value(3.14, 2) << std::endl;
} 

expression min_value(3.14, 2) causes implicit instantiation of min_value<double, int>, so we don't need to do anything special to make linker happy in this case.

If we had something like this

// translation unit 1
#include <iostream>

template <class T>
    T square(T const &x);
// no definition of square is available in this translation unit

int main()
{
    std::cout << square(3.14) << std::endl;
} 

then some other translation unit would have to explicitly instantiate the definition of square<double>:

// translation unit 2

template <class T>
    T square(T const &x)
{
    return x * x;
}

template double square(double const &); // explicit instantiation of square<double> 

[]KAOS[]Casey wrote on Sep 9^th, 2016 at 8:16am:

yes, for whatever that expands into __declspec(dllimport) and is used without a reason.

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.