filthydumbidiot

Freebooting is certainly more specific than piracy, but I think you may have missed the word "like" in there. GP means that the word "freebooting" itself is not new, but its new meaning in today's context is (like "pirate") new.

In short, emphasize the skills and experience you do have. Apply and interview far and wide at all the companies that remotely interest you.

A bit of background: I have been coding since an early age and hold an arts degree. I had no serious experience in the industry a few years ago, but had work experience in other fields and I had many independent projects to showcase. I have been gainfully employed in software for the last few years as I approached 30 myself. Now I feel somewhat established enough that the arts/self-taught background is not as big of a deal as it seemed when I was just trying to break into the field. They even have me performing technical interviews now for some reason, which I'm mentioning to show that I've now been on both sides of the table.

My advice to you is to build your resume around the skills and experience that may be unconventional but are as relevant to the job you want as possible. Where most people would have job experience or education front and center, I placed a rundown of projects that detailed what techs I used to accomplish what ends and what results I got out of each project. These may have been even unreleased, work in progress personal projects (clearly stated as such), not for profit projects or websites or communities that I had a technical hand in creating, open source software contributions, and so on. Of course, if you don't have any projects to show at all then you should work on that before trying to get a job. But I assume you have some personal stuff, even incomplete and unseen by anyone, that you can showcase to demonstrate your skills. Links to working demos are a major plus, and you should always prefer concise descriptive text over just namedrop lists.

I list work experience where I think it is relevant to the job in software. Any previous office experience, for example, can at least show that you know how to work on a project, meet deadlines, act professionally (arguable), etc. Highlight the transferable skills of your previous employment. Likewise, highlight the transferable skills of your degree. It often became a point of intrigue that I had this esoteric degree after we've talked in-depth about programming for an hour -- so don't think of it as a weakness. In your resume, stay focused on the goal, which is to get a job in software. Do not use a generalist resume as your software resume.

Finally, pound the pavement. Do not wait. Tweak your resume and send it out often. I lost track of the number of companies that I've actually applied to, but in getting my first job I had in-person interviews (sometimes multiple rounds) at over 10 companies. I flat-out bombed some interviews. It didn't click in others. And sometimes it seemed like I was going to get the job, but with my untested background it was too 'risky' or I was too 'junior'. Don't let this stop you from going to the next interview. Embrace rejection and use it as an opportunity to learn. Try to strike a balance between quantity and quality in the jobs you apply for. Be directed and intentional in that you only apply to jobs that actually interest you and that you actually think you can do (so no "Sr. Dev", of course), but don't be so focused on one or two companies that you just sit around watching their careers page for an opening. Find a middle ground somewhere between "The One True Dream Job" and loading 100,000 copies of your resume into a biplane and dumping them over the city. In my case, beyond the usual job sites, I got a list of all the tech companies in my city in some local tech magazine's annual hottest tech company edition (or whatever it was) and went through the list applying to every single one that seemed like it would fit. And that got me my first job in tech, which has been utterly game-changing.

Others have already mentioned that you need to practice that awful hurdle that is "the coding interview". So be sure to do that as well, and take every interview as a learning experience. Hope this helps.

Interesting. Here's a similar project from a couple years ago:

http://sarvagyavaish.github.io/FlappyBirdRL/

To get an image of how the language grew (from a mid-90s perspective), you can read "The Design & Evolution of C++" by Bjarne Stroustrup. Then read "The C++ Programming Language (4th ed.)" to understand the new parts. And read "C++ Core Guidelines" (free on GitHub!) to grasp some best practices in modern C++. And, of course, practice.

"You are hearing me talk." -Al Gore-ism

Judging by your capitalization, you must be of the BASIC school of aesthetics...?

Or BF Joust:

https://esolangs.org/wiki/BF_Joust

Note also that the real cost of the pool allocation is up front in the "Pool construction" field. At 368ms in this benchmark, it takes even longer than all of the heap allocations!

With pools, you pay an up-front cost for the faster allocation later. So a better way to arrange the benchmark would be showing off frequent pool creation and deletion of objects.

By explicitly calling the destructor, you could do away with the requirement that classes must implement a "reset()" member function (which, aside from being an extra step for users, does kind of make RAII in their classes somewhat confusing):

  void release(OBJ* obj) {
    // ...
    obj->OBJ::~OBJ(); // OBJ was the template type
    // ...
  }

acquire() could be improved by using placement new and forwarding the constructor arguments via variadic template:

  template<typename... T>
  OBJ* acquire(T... args) {
    // ...
    return new(mem) OBJ (args...);
  }

Finally, you can exchange potential upfront construction cost (and remove the need for a default constructor in user classes) by making an inner dummy struct that matches the size:

  template<typename OBJ, int32_t NUM_OBJS>
  class Pool {
    struct MockOBJ {
      uint8_t data[sizeof(OBJ)];
    };
    
    public:
      Pool(){
        // ...
        std::for_each(std::begin(_available), std::end(_available),
          [](OBJ*& mem){mem = reinterpret_cast<OBJ*>(new MockOBJ);});
        // ...
      }
  // ...
  };