My Visual C++ 2019 settings

Just for the record, these are the settings I’m always using with Visual Studio 2019, when creating a new, empty C++ project:

• General
  • Output Directory: $(SolutionDir)$(Platform)_$(Configuration)\
  • Intermediate Directory: $(Platform)_$(Configuration)\
  • C++ Language Standard: ISO C++20 Standard (/std:c++20)
• C/C++
  • General
    • Debug Information Format: None (Release)
    • Treat Warning As Errors: Yes (/WX) (Release)
    • Multi-processor Compilation: Yes (/MP)
  • Code Generation
    • Runtime Library: Multi-threaded (/MT) (Release)
• Linker
  • Debugging
    • Generate Debug Info: No (Release)
  • System
    • SubSystem: Windows (/SUBSYSTEM:WINDOWS)

As of April 2024, the settings above also apply to Visual Studio 2022.

Adding a branch from another repo in Git

This should be something rather rare, but for some reason I keep needing to do it very often: I want to add a new, unrelated branch into an existing repository, and this branch comes from another repository.

While needing to do this yet again today, I found a rather elegant solution here:

git switch --orphan NEW_BRANCH
git pull FORK_URL FORK_BRANCH

It works remarkably well and clean. Props to the guy who shared this.

Deep cloning a generic List in Java

Today I had to deep clone objects in Java. What a nightmare.

First, the Cloneable interface is horribly broken, and writing such a simply code becomes a laborious task. Second, if the object has a List as a field, you must manually clone the elements into a new List.

The code goes as it follows:

public class Foo implements Cloneable {

	private String name;

	private List words;

	@Override
	public Object clone() {
		try {
			Foo cloned = (Foo) super.clone();
			cloned.words = Auxiliar.cloneList(words);
			return cloned;
		} catch (CloneNotSupportedException e) {
			System.out.println("Never happens!");
			return null;
		}
	}

	// Getters and setters omitted.

}

Notice the Another.cloneList() call? This is where we manually clone all the List elements, by calling clone() in each one. This is the solution I found for a generic method:

public class Auxiliar {

	@SuppressWarnings("unchecked")
	public static <T extends Cloneable> List<T> cloneList(List<T> list) {
		try {
			List<T> newList = new ArrayList<>(list.size());
			for (T item : list) {
				newList.add((T) item.getClass().getMethod("clone").invoke(item));
			}
			return newList;
		} catch (IllegalAccessException | IllegalArgumentException
			| InvocationTargetException | NoSuchMethodException | SecurityException e) {
			System.out.println("Never happens!");
			return null;
		}
	}
}

No idea why Cloneable was not deprecated and replaced by something minimally decent yet.

Gibson fretwire

Apparently with my Gibson Les Paul craze back again, I’ve been dabbling into the specs of the High Performance series. The specs list the fretwire as “Low”, without any further info on the actual dimensions. Also, other models are listed as having “Medium Jumbo” fretwire. What do they mean?

Fortunately Gibson Customer Service kindly answered my emails, and these are the measures:

Fretwire	Height	Width
Medium Jumbo	.055"	.090"
Low	.045"	.086"

This information, paired with this fretwire chart and our JP chart, gives us a good comparison with commonly known fret sizes:

Fretwire		Height	Width
Dunlop	6000	.058"	.118"
	6100 (Ibanez JPM)	.055"	.110"
	6105 (Ibanez JEM)	.055"	.090"
	6140 (Ibanez Universe)	.039"	.106"
EBMM	medium jumbo (Majesty)	.051"	.108"
	high wide (JP6)	.047"	.104"
Suhr	jumbo	.057"	.110"
	medium	.055"	.090"
	heavy	.051"	.108"

I just can’t understand, however, why would they use vintage frets in such a modern guitar.

Accepting both Vec or slice of String or &str in Rust

In whathever programming language, it’s rather common to have a function which accepts an array of strings. Specifically in Rust, there is the notion of slice, which can be used as a reference to a Vec. And also there is the notion of &str, which can be used as a reference to String. Putting both concepts together as an argument is not trivial, though.

Turns out I found a way to make it work by using the AsRef trait – as many things in Rust, traits lead the way. By using generics, it becomes possible:

fn foo<S: AsRef<str>>(names: &[S]) {
	for name in names.iter().map(|s| s.as_ref()) {
		println!("{}", name);
	}
}

Or alternatively using the impl keyword for the trait bound:

fn foo(names: &[impl AsRef<str>]) {
	for name in names.iter().map(|s| s.as_ref()) {
		println!("{}", name);
	}
}

The function above accepts both Vec and slice of String or &str. But notice how, in order to retrieve the string itself, the as_ref() method must be called.

About these 10 years

Hello, dear reader.

I started this blog exactly 10 years ago, in a Saturday morning, without having much idea about what I’d write here. I just wanted a safe place to vent.

Now, after 10 years, there’s quite an interesting content written down. In many ways, it’s a window to see my own maturing on various topics. Things that matter – or mattered at the time – to me, and nobody else. Well, actually some posts did generate outsiders’ interest but that’s not the point: this is a personal blog in the most actual sense.

But the thing is that it feels like it was yesterday. 10 years went by.

Missing the ternary operator in Rust

Just out of curiosity, I wrote a Rust macro similar to Visual Basic’s IIf function:

macro_rules! iif {
	($cond:expr, $iftrue:expr, $iffalse:expr) => {
		if $cond { $iftrue } else { $iffalse }
	};
}

Usage:

let n = iif!(1 == 1, "yes", "no");

Close to the ternary operator, which I’m sorely missing in these Rust days.