I've been disconnected for a while now, the last post was like, a month and a half ago. The frequency of posts might settle down to two per month now (I hope that at least that will be true).

But, I'm back, and also I'm coming with some thoughts and news of what I'm working on now.

C++, Why now?

As you might have noticed, I'm mainly a web developer and studied basically in managed environments like Java™ or C#™. Anyway I never stick uniquely to a language. I think that programming languages are just like real ones: Learning new ones stimulate your brain and bring you new points of view, which I find personally very exciting.

Anyway, to the point: Why C++ now? Well, I've done some experiments with it in the past and programmed dummy things when I was a teenager, like this... um... "LCD Shield Driver" on github, okay you can laugh at it! I was so dumb that I didn't even care about inheritance, but that might be material for another post.

The thing is, that I'm working on a game (whoa, what a surprising new!), with a custom engine that uses SFML library.

Image source: sfml-dev.com

So, that is the source of all those "Head scratches" that I'm having right now. I've never done any real world application in C++ nor any that manages long lived objects in it.

All that painful work was done in my past by garbage collectors and memory management from platforms and languages like JS, Lua or Java, but now I'm facing the beast on my own, and that is why I had that little stop of one month, It's hard to keep the peace when you have something that absorbing.

First thoughts

Well, you'll probably see more posts about this topic in the following posts, because I think that one post might not be enough for all the things that blow my head, also I don't want to bore the reader (you!) with 486935 paragraphs in one page!

My first thoughts were like "HOAH MAN! You can archive like super meta things statically! On compile time" and tons of concept that sounded cool, but had no fucking clue of what they mean or even if I was mixing them.

#define THING(a, b) int a = b + 32
#include <iostream>

using namespace std;

// WHOA RETURN SOMETHING MAGIC
int main() {
  THING(cool, 5); // DO THE NINJA FOO
  cout << "LOOK MOM: NINJA STUFF! " << cool << endl;
  return 0;
}

I have to admit that those new concepts like macros shocked me at first, causing that my first tests in C++ were more like macro-zombies from a Mary Shelley's novel.

Well, I was a teenager and doing ninja foo code seemed cool. That's something I'm not proud of, but all we have regrets from adolescence, don't we?

Okay, let's skip "first" then

So as I already knew C++ vaguely (Things like you've seen up there...), we're going to focus on what I've found out now in 2018/2019.

First concept: The "RAII" (Resource Acquisition Is Initialization). This is something that I didn't even know that had a name, and blew up my mind the first time I tried something like:

class DumbClass {};
int main() {
  DumbClass* ptr;
  {
    DumbClass diesYoungSadly;
    // Do things with that dummy class...
    ptr = &diesYoungSadly;
  }
  // Yeah play more! Your object is alive! Right? Right...?
  moreFunnyThings(ptr);
}

Yeah! Do things, at least you have ONE reference to it right? RIGHT? Well, no. That might sound very obvious for someone that has experience at C/C++ but don't be rude, if you come from a managed background that might not be that obvious.

The worst of all is that the program might not even crash! You're playing with a zombie DumbClass and the program is still doing things with it!

That... Drove me crazy many times, specially when wasn't that obvious that the object was already dead, accidentally.

That leads us to the second worst thing: Unexpected behavior.

What on hell does that even **** mean?!!?! Me trying to understand C++

Well, usually when I program at work or things that are not related to Arduino™ or this mysterious game engine, anything should end up in a "Unexpected behavior". Either does throw an exception, crashes or notifies you somehow.

But we're no longer at home right?

Well, no, not at all. For that reason, I'm trying now to wrap around all those possible fatal-demon-summoning code fragments safe walls that will (Hopefully) prevent me from... Exploding...? I have no code fragment at the moment to show what I mean, but I think you get the point.

Not everything was that bad!

But hey! Not all impressions were bad, templates and deduced types feel more light than ol' classy' generics in Java!

template<class T>
class Some {
public:
  T thing;
};

auto magicSum(auto a, auto b) {
  return a + b;
}

int main() {
  Some<int> intHolder;
  intHolder.thing = 5;
  // Or...
  int sum = magicSum(2, 2);
}

So, like every almost language I've tried seriously, the feelings were more like a roller coaster, ranging from love to hate in no time.

I don't remember if I've mentioned it, but I like programming in Typescript™, why? Well, it's cool because integrates with Javascript but that can be replaced by others like Dart or Coffeescript or anything that can be transpiled to Javascript.

The thing is that Typescript offers static typing, which offers you lots of guarantees when it comes to error safety, but, the coolest thing is the whole set of structural checks that performs before compiling.

A great example: The "safe" duck typing!

interface Duck {
  cuack(): void;
}

Usually, you should implement that interface in statically typed languages, but is not necessary in Typescript if your class (or even plain object!) does satisfy it structurally:

class SomeDuck {
  cuack() {
    console.log('CUACK!');
  }
}

function doCuack(thing: Duck) {
  thing.cuack();
}

const someDuck = new SomeDuck();
doCuack(someDuck);

And that is totally fine for Typescript! For those who haven't heard about "Duck typing", in short means that if the object satisfies what you need of it, it's valid, or:

If it walks like a duck and it quacks like a duck, then it must be a duck Wikipedia article, source: wikipedia.org

Usually, that statement makes me feel discomfort when working with dynamic typing, but if it's checked statically is okay!

So what I'm trying to archive now (For sake of simplifying the API of my game) is that: Statically check structural needs.

The sad reality

But the truth is that, although possible, C/C++ compilers do not like this.

At first, the intelisense will not complain: (sorry for those stupid names, it was dark and I was sleepy)

But then! The compiler will say "STOP RIGHT THERE!", because the code is wrong of course:

Sorry, the errors are in spanish, basically is saying 'quack' is not a member of 'Jagaimo', but like repeated 100 times and a little bit cryptic.

Final thoughts

So what I'm trying to achieve now is the balance between automatic or deduced type checks, and the classic polymorphism principles.

Now, spoiler time! Here, have a picture of a weekend project that I'm working on:

See you in two weeks or so! What do you think? Do you have those problems?

Or even better... Do you know the key to my headaches? Thanks for reading!!!