next »

[powly]

In C or C++ things like that can be slightly hazardous since there is no explicit guarantee of execution order inside all possible statements -- most notably function arguments can be processed in any order and this can (read: will) be different on different compilers.

[Dacke]

function arguments can be processed in any order

 

reason one billion and three I'm happy I moved away from C/C++

[oahda]

In one of the recent cppcon talks I watched they said something about C++ having (going to have?) a strict execution order as opposed to C in some new standard.

[InfiniteStateMachine]

Does the order that function arguments are processed have anything to do with the calling convention or is that unrelated?

[Cheezmeister]

Eh, C and JS both give you lots of rope to hang yourself with, just that one's more like braided jungle vines and the other, twined EL wire. It's one of the reasons I love both languages (and why many people hate them!)

JavaScript: The Good Parts gives a lot of historical insight into why JS is weird like it is (spoiler: marketing/corporate BS) and also how to not hang yourself. I'm not sure how relevant it'll stay with ES6, they changed a LOT of stuff, mostly for the better.

[Garthy]

JavaScript: The Good Parts gives a lot of historical insight into why JS is weird like it is

I was going to crack a joke about the title of the book, but...

https://twitter.com/turingmachine/status/636688576655134720
https://twitter.com/BillB/status/636694624254361600
https://twitter.com/foldablechair/status/636887432819023872

There's quite a few gems here:

https://twitter.com/ID_AA_Carmack/status/636688445398618112

[Dacke]

oh JS, you scoundrel

[oahda]

That might actually be useful when writing something that's supposed to ignore whitespace, I guess!

[standardcombo]

Also useful for making code that is impossible to maintain.

[Cheezmeister]

Job security, yo.

[oahda]

Also useful for making code that is impossible to maintain.

Well, I don't see any reason to compare a string to a number normally, so it would really only be done on exceptional occasions like this.

[Dacke]

Except that JS in untyped, so if you embrace that then your variables can be whatever whenever. So sometimes you may be just be comparing numbers as usual, but then maybe once in a while you send in some strings as well. The sky's the limit!

[oahda]

Right, "0" would be 0 too, right? And perhaps "false"? Now that I think about it, I remember reading an incredibly frustrating list about the results of all sorts of comparisons in JS! Would be fun to find that again...

[Dacke]

Code:

0 == "0"
true

false == "false"
false

and this is why you usually should be using === for this kind of stuff in JS

[oahda]

Yeah, I know JS decently well—my mind just slipped for a bit and I didn't realise that the whitespace check wasn't failsafe.

*shame forever*

Makes one wonder about the point of that rule then, since it cannot be used to reliably check for whitespace anyway. Then it seems completely arbitrary.

[oahda]

Apparently in C# one can't simply call a lambda at the time of its creation:

Code:

(() => { … })()

This does not compile! C# doesn't know how to run a lambda between parentheses and a call operator like this. It has to be casted:

Code:

((System.Func<bool>)(() => { … }))()

A horrible mess, even if one imports System and can take that off of Func (but that's not something I usually want to do in Unity, because there are some fairly common clashes between System and UnityEngine)!

In C++ you don't even have to surround the lambda with parentheses to do this:

Code:

[]{ … }()

 

[Dacke]

ew

But is it at least possible to import Func and not all of System? Something like Imports System.Func?

[oahda]

Partially. It's possible to do something similar with aliases:

Code:

using Enum = System.Enum;

However, Func is templated and has several template overloads, and aliases cannot be templated. What I can do is import a particular template:

Code:

using FuncBool = System.Func<bool>;

But I cannot do this:

Code:

using Func = System.Func;

Modern C++ actually added this exact alias syntax in addition to its old typedef syntax, so these are valid statements in C++ as well, but C++ does support templated aliases, so there I could do this, with a variadic template (I don't think C# has variadic templates either tho, but instead they've manually defined Func with increasingly many template parameters or something?):

Code:

template<typename... Ts> using Func = System.Func<Ts...>;

[InfiniteStateMachine]

UnityEngine and System collide? That's not very good. That's something Unity could have easily avoided.

[oahda]

UnityEngine and System collide? That's not very good

Well, they're in namespaces for a reason (System and UnityEngine are namespaces). c:

They only collide if I decide to "use" them with the using statement (basically the same as using namespace in C++), so they don't collide by default. But Object and Random exist in both (and I only ever use the Unity versions), so on the relatively rare occasion that I need something from System, I just prefix those things with the namespace. Meanwhile I use lots of things from Unity's namespace(s) all the time (not a surprise when that's the engine I'm working in), so I do "use" those.

Note that they're still accessible without the using statements (I just have to specify the full namespace path). C# doesn't usually use anything akin to import or #include; it's just magically available if the parser can find the files.