matt77hias

But that is also the case for WRL. C++/CX uses language extensions. unmanaged/raw C++ with WRL does not use language extensions. With regard to the C++/CX monstrosity, I would definitely choose C++/WinRT. With regard to unmanaged/raw C++ with WRL, I don't know.

At first glance, the WRL to WinRT mapping seems just like a bijection. But I have nothing against another COM facade.

Basically, I like to switch without any performance decreases or functionality limitations. The statement: also indicates greater flexibility with regard to other C++ compilers. MSDN provides some simple guidelines to perform the switch, but these seem to be true small to suffice. Currently, I do not use C++/CX, but just unmanaged C++. But Wikipedia mentions: So this holds for both unmanaged C++ and the weird looking C++/CX (e.g., added ^ syntax elements).

Do the same restrictions with regard to the swap chain configuration as for UWP hold? Given that I do not intend of creating UWP applications, does it make sense to use WinRT?

What are the benefits of switching from unmanaged C++ to C++/WinRT? Is it just a "more modern" C++ API or are their functionality and/or performance changes as well?

But this is only about the loop itself, not about the conditional operations regarding each bottle?

But even if you don't bother the API user with such internal state, shouldn't you still have some internal mechanism to perform your own garbage collection at certain points to amortize the cost? Besides not active != dead, right?

MIPS has 5 (still not close to the deep ones such as PPE's 23). So an elementary op will be delayed for 5 cycles, which does not look like a real issue. Even when the clock rate is typically lower, this affects the other ops in the same way, so the relative penalty of n cycles remain independent of the clock rate.

With colors, I guess you do not mean vertex colors (e.g., Gouraud shading), but rather submodel colors?

Like I said, all major compilers (gcc, clang, icc, msvc++) do the same thing for the second and third one, but I read on SO that some people obtained differences on some architectures in favor of the ternary operator. (Though, it still depends on the number of expressions of AddLiquid. The smaller AddLiquid, the higher the chance of already having the code beyond the conditional in the cache).

Of course, but the exercise basically states some architecture requirements and I do not have such an architecture. My Intel CPUs are monsters with regard to branch prediction 😉 Though, I am going to partition my data in advance O(n) to put the empty ones at the back. This will basically remove all the inner branches. The partitioning comes at a price as well, but branch misses are less expensive.

Just some programming exercise about an hypothetical architecture (maybe we can think of a graphics calculator ) with no branch prediction.

Assume, we have some old embedded CPU architecture completely lacking branch prediction, implying a serious overhead in case of branching. So in the below esoteric example, we will perform quite some branching on average: if (HasLiquid()) { for (auto& bottle : m_bottles) { // Contiguous memory if (bottle.Empty()) { bottle = AddLiquid(); break; } } } We can eliminate the branching overhead, by avoiding early loop and function termination: bool has_liquid = HasLiquid(); for (auto& bottle : m_bottles) { // Contiguous memory const bool empty = bottle.Empty(); const bool fill = empty && has_liquid; bottle = fill ? AddLiquid() : bottle; has_liquid = fill ? false : has_liquid; } which will be pretty similar (though, someone observed better assembly for the PS3 in case of explicit ternary operators) to the following snippet as well for all the modern compilers: bool has_liquid = HasLiquid(); for (auto& bottle : m_bottles) { // Contiguous memory const bool empty = bottle.Empty(); const bool fill = empty && has_liquid; if (fill) { bottle = AddLiquid(); has_liquid = false; } } This is maybe even better, since re-assigning the same value in case of fill == false, is just boilerplate for us trying to outsmart the compiler and overhead for the compiler itself. Given, however, that iterating all bottles is the realistic worst-case behavior, which can seriously impact our overall update frequency, why shouldn't we go with the 2nd or 3th snippet? Or stated differently, the latency of the latter snippets has less outliers and variance, and thus will result in a smoother update frequency (in isolation).

How do you configure the DirectXShaderCompiler to output warnings for float -> (u)int conversions? Apparently, the compiler does not complain at all when using the default project options. Furthermore, while looking at the project options in Visual Studio, I do not see any warning level related options (as is the case for C++ code).

How can I redirect all https://www.A.net/Page.html requests for some page Page.html to the corresponding page on another domain https://www.B.net/Page.html via the https://www.A.net/404.html? Github/Gitlab Pages redirects all Page-not-found errors to the latter. Is it possible to somehow retrieve the original requested page and use this in a Javascript (jQuery) function to modify the redirection URL? I currently use something like the following HTML code for a many-to-one redirection, but I rather need a one-to-one redirection (i.e. not always to the same https://www.B.net/404.html). <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"/> <meta http-equiv="refresh" content="0; URL=https://www.B.net/404.html"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"/> <meta name="viewport" content="width=device-width; initial-scale=1.0"/> </head> <body> You are being redirected to https://www.B.net/404.html <a href="https://www.B.net/404.html">https://www.B.net/404.html</a> </body> </html>