michaelbartnett

using System;
using System.Collections.Generic;
using UnityEditor;

public static class TestBoxing
{
	//
	// Constructors
	//
	static TestBoxing()

michaelbartnett

(defun make-cc-code (input-string)
  (let ((charlist (mapcar (lambda (c) (coerce c 'character))
                          (split-string input-string "" t))))
    (loop for c in charlist
          for i below (length charlist)
          collect (lsh c (* i 8)) into shifted-charcodes
          finally return (apply #'logior shifted-charcodes))))

(mapcar #'make-str-codes '("NONE" "STRN" "INT4" "FLT4" "BOOL" "ENUM" "ARRY" "COMP" "UNON"))
; => (1162760014 1314018387 877940297 877939782 1280266050 1297436229 1498567233 1347243843 1313820245)

michaelbartnett

Why do compilers even bother with exploiting undefinedness signed overflow? And what are those
mysterious cases where it helps?

A lot of people (myself included) are against transforms that aggressively exploit undefined behavior, but
I think it's useful to know what compiler writers are accomplishing by this.

TL;DR: C doesn't work very well if int!=register width, but (for backwards compat) int is 32-bit on all
major 64-bit targets, and this causes quite hairy problems for code generation and optimization in some
fairly common cases. The signed overflow UB exploitation is an attempt to work around this.

michaelbartnett

DynArray<TypeMember> clone(const DynArray<TypeMember> &memberset)
{
    DynArray<TypeMember> result = dynarray_init<TypeMember>(memberset.count);

    for (u32 i = 0; i < memberset.count; ++i)
    {

        TypeMember *dest_member = append(&result);
        ZERO_PTR(dest_member);
        NameRef newname = src_member->name;

michaelbartnett

ParticleSystem ps = GetComponent<ParticleSystem>();

ps.enableEmission = false;
// warning CS0618: `UnityEngine.ParticleSystem.enableEmission' is obsolete: `enableEmission property is deprecated. Use emission.enable instead.'

ps.emission.enable = false;
// error CS1061: Type `UnityEngine.ParticleSystem.EmissionModule' does not contain a definition for `enable' and no extension method `enable' of type `UnityEngine.ParticleSystem.EmissionModule' could be found (are you missing a using directive or an assembly reference?)

ps.emission.enabled = false;
// error CS1612: Cannot modify a value type return value of `UnityEngine.ParticleSystem.emission'. Consider storing the value in a temporary variable

michaelbartnett

// I posted this because I remembered a small twitter conversation about ternary operator vs if, and randomly
// found myself purposefully choosing to use ternary and wanted to highlight my reasons in case there's
// any other weirdoes like me think it's fun to talk about this sort of thing.
//
// The important part is what value is assigned to tutorialNumber, and I think that ternary operator better
// highlights where and how that changes than an if statement does.

    private void ShowReminder(Reminder reminder)
    {
        Assert.AreNotEqual(reminder, Reminder.None, "Can't show the 'None' reminder");

michaelbartnett

// I have some enum ranges that I'm trying to keep in sync:

// I have some powerups:

enum PowerUpID
{
    Missile,
    Bomb,
}

michaelbartnett

(defun print-joystick-axis-config (joynum axis-index)
  (let ((axis-def-fmt  "  - serializedVersion: 3
    m_Name: Joystick_%i_Axis_%i
    descriptiveName: 
    descriptiveNegativeName: 
    negativeButton: 
    positiveButton: 
    altNegativeButton: 
    altPositiveButton: 
    gravity: 1000

michaelbartnett

/* in switch statement: */
case GameState.Finished:
    playerFinished = true;
    goto case GameState.Quitting;
case GameState.OutOfTime:
case GameState.Died:
case GameState.Quitting:
    // etc.
    
    

michaelbartnett

namespace UnityEngine
{
    public class Object
    {
        //
        // Operators
        //
        public static bool operator ==(Object x, Object y) {
            return Object.CompareBaseObjects(x, y);
        }