

XRay Unreal Engine 4.5 source code - cppdesign
http://www.codergears.com/Blog/?p=965

======
maccard
Although this article points out that UE4 doesn't use synamic_cast, Unreal
implements a full reflection system and uses it instead. Similarly, if you
searched for uses of stl, you'd be is appointed because everything is
reimplemented as TArray, TPair, TMap, etc.

~~~
desdiv
_if you searched for uses of stl, you 'd be is appointed because everything is
reimplemented as TArray, TPair, TMap, etc._

In case anyone else is wondering "why didn't they just use STL?", here's an
answer from an Unreal employee:
[https://answers.unrealengine.com/questions/2695/rocket-
and-t...](https://answers.unrealengine.com/questions/2695/rocket-and-the-
stl.html)

------
illicium
> ⁎((uint32⁎)3) = ExceptionCode

Is this just a way to force a segfault, or clever sorcery? What is significant
about the pointer 3?

~~~
omnigoat
They're calling the Int 3 debugger instruction, I believe:

[http://en.wikipedia.org/wiki/INT_%28x86_instruction%29](http://en.wikipedia.org/wiki/INT_%28x86_instruction%29)

I'd prefer to see this either with inline assembly, or using __debugbreak()
(and variants for other compilers). I'd say it's a deref because many
compilers don't generate inline-asm for 64-bit skus. This makes the
instruction always emitted, and then 64-bit platforms ignore it. But not
always (recent claims say it works:
[http://stackoverflow.com/questions/3634124/where-did-
int-3-g...](http://stackoverflow.com/questions/3634124/where-did-int-3-go)).

~~~
pandaman
Int3 is a one byte instruction, how do you imagine this code could possibly
compile into one byte? This will compile into several moves/stores. Not to
mention the code is not x86 specific at all.

It's a forced memory access violation and the 3 is used to distinguish it from
a natural one: when you hit this you will see an immediate 3 load nearby and
that's a constant that is rarely seen in code normally.

~~~
leetNightshade
"Not to mention the code is not x86 specific at all."

Technically no, however it's only used in x86. It's only ever called if
PLATFORM_EXCEPTIONS_DISABLED is 0. If you look up where
PLATFORM_EXCEPTIONS_DISABLED is defined in Platform.h, you'll see it's only
defined when not using PLATFORM_DESKTOP. PLATFORM_DESKTOP is disabled for
Android, HTML5, iOS, WinRT, and WinRTArm. PLATFORM_DESKTOP is enabled for
Linux, Mac, and Windows. So that instruction is only intended to be used in
x86 desktop environments.

Considering this, I don't think RaiseException is well defined. If it's only
meant to be used for x86, it should be coded that way instead of relying on
other code to enforce the behavior.

~~~
pandaman
>It's only ever called if PLATFORM_EXCEPTIONS_DISABLED is 0

Quite the opposite. The ! operator means a logical negation.

~~~
leetNightshade
if PLATFORM_EXCEPTIONS_DISABLED means if it is not 0. if
!PLATFORM_EXCEPTIONS_DISABLED means if it is 0, if it is not disabled. I said
nothing incorrect, I'm well aware of what it means.

~~~
pandaman
You said the code is being called only if PLATFORM_EXCEPTIONS_DISABLED is 0.
This is incorrect. Just compile that function and set the breakpoints if you
cannot figure out the #if/#else logic.

~~~
leetNightshade
It's getting hit because you're running on Windows/Mac and Windows/Mac
specific methods are calling it. In platform generic code like
OutputDevices.cpp you see this:

    
    
        #if PLATFORM_EXCEPTIONS_DISABLED
        		FPlatformMisc::DebugBreak();
        #else
    		FPlatformMisc::RaiseException( 1 );
        #endif

~~~
pandaman
I see. You are saying that because a library/framework is not calling one of
its own functions in a certain configuration nobody ever going to call this
function in that configuration, right? I am not sure I can join you in this
belief, after all there are not that many fully recursive libraries so some
functions will never be called in almost every library.

~~~
leetNightshade
"You are saying that because a library/framework is not calling one of its own
functions in a certain configuration nobody ever going to call this function
in that configuration, right?"

I'm not saying that at all, I said early on that this is a problem. Refer to
this in my first comment replying to you: "I don't think RaiseException is
well defined. If it's only meant to be used for x86, it should be coded that
way instead of relying on other code to enforce the behavior."

Internally it seems they only intended it to be used in specific cases, but
there's nothing preventing anyone else from calling it when they shouldn't as
you noted. This is bad design.

