Do You Have Any Recommendations For A Small Project To Build Using C++? I've Been Interested In Learning

Do you have any recommendations for a small project to build using c++? I've been interested in learning c++ for gamedev in godot. I already have programming experience so I woudn't be starting from the basics (and I own A Tour of C++ by Stroustrup), but at this point I'm wondering whether I should just go through A Tour and then just get stuck into some sort of game idea.

I am not familiar with godot (It is on the list... might honestly look into it in a weeks time) I will steal some advice from Jason Turner. Pick a project you think you can do. Because it will be harder than you think. That is just how it is until you get more experienced. In the meantime, as soon as you have the basics (Writing and calling functions, and classes ) I would start doing something that will require Architecture. Not a lot, but something that requires several distinct parts. Thinking gamedev, maybe a character on screen moving. If it seems like a lot to do, then try figuring out how automated tests works in godot. And then write a program that writes basic ZOMBIE tests for a function. You will learn a lot, and will help you write tests for your code later. Try making a very simple BDD diagram before you start. Simply to force you to think about what it is you want. Keep them simple. Here is mine for my robot PROTO:

Simple boxes, arrows, and explanations for myself to keep things clear. And PROTO is a complex system with many moving parts. Yours should be way way simpler. Arrows and boxes makes everything clearer. And then start coding! When classes or functions get too big, split them up. If you have trouble splitting them up without everything being dependent on everything, try drawing the diagrams again, and ask yourself what you are really trying to do with that chunk of code, and see if there are any software patterns that fits your needs. Refactor your code after you get it to work, make it easier to change and read. Ignore efficiency. pre-mature optimization is how projects die. Make the code easy to read and easy to change. If you run into efficiency issues later then it will be easy to fix. And keep making the simple diagrams. They will help you become better, by having you think about your plan, and how you are coming along. I hope this was helpful ^~^

That is great! Being able to state positive things about yourself is a really great skill! Honestly, it is good for your mental health and outlook!

Study affirmations

🏹 Studying is very easy for me.

🏹 People are always in awe of how easily I'm able to understand and retain information and get good marks.

🏹 I'm the smart friend in the friend group.

🏹 I study multiple courses at a time and yet score perfectly.

🏹 I'm a genius.

🏹 I'm a prodigy even though i didn't realise it until recently.

🏹 I thought I was an average student but i didn't realise how easy it is for me to study and get great marks.

🏹 Everyone idolizes me when it comes to being an idol student.

🏹 People are in awe of my knowledge.

🏹 I study when I'm tired because it helps me relax.

🏹 I do not waste my time.

🏹 I sometimes even hyperfocus on my course because it's so damn interesting!

🏹 I'm the Queen/King who always fascinates people with my presence.

Love you. ❤️

Designing systems with bad Implicit requirements. (Or "How to hire people")

So I have now been searching for a job for half a year. And my conclusions are: 1: Firms have no idea what they are doing. Everyone seems to make decisions based on "What does everyone else seem to be doing" and "How do we usually do it" 2: Your ability to do the job you are applying for have just about 0% relevance in your ability to GET the job you are applying for. I am a system designer. And when I get exposed to the same system many times, I start analysing it... it is basically habit at this point. And so, I analyse the hiring system. And so far, in all the interviews I have been to I have been asked 0 technical questions about the position I was interviewing for. 0! And the little feedback from my many many rejections, was that I am not experienced enough. That is weird. Because they are making a judgement on how skilled I am... while not at all asking about or testing my skills. And yesterday I finished my internship (Which is a polite way of saying "Whored myself out for 0 pay in desperation"), and I was in a room with 6 other developers, who was all programming in C++ And I now know that I was the best person at C++ in that room. Better at designing with C++, building architecture with it, knowing the intricacies of the language, and knowing tiny weird little details of the language. (Most of the others had different things they were better at. More experience working with the specific hardware and codebase at the job, better at 3D simulations and so on) So I know for a fact I am skilled. But the system that is build with these interviews mean that skills do not count. Someone with terrible skills who had done bad work at their student job for a year or two, is considered better than someone with great skills who have focused on their studies and not yet worked. Or said in another way. There is an implicit specification in the system design that "Being good at the job, does not matter" So since that is frustrating as hell, and I need to interact with it to stop my brain exploding, lets design a better system. First of all, the OBVIOUS (That... I have seen exactly 1 firm do):

Blind recruitment.

The system will have to have humans make the judgement of who to call into interviews, and who to hire. And humans are stupid little monkeys with brains with software that is just layers covering for the flaws of other layers. Yes, that also means you. And yes, that also means me. We are biased. You can try to constantly evaluate yourself, be aware of your biases and minimize them, but they cannot be removed. Science ( as in, the entire field , have tried for several hundred years and is only "meh" at it So how do we deal with that? We remove the info that is not needed, and can ONLY lead to bias. A person making a judgement if a candidate should be called in for a interview should not know the candidates gender, name, age, skin color, religion or any other information we can remove that have no value when it comes to figuring out if that person will be good at their job. You may think "Hey wait a minute. Age DOES have an influence!" but it really does not. EXPERIENCE does, and SKILL does, and PERSONALITY does. And yes, age can corelates with that. But that is it... it MAY corelate with it. We want to value 2 people with the same skills, and the same experience in the relevant fields equally, if they are 25 or 40.

Throw the letter of motivation in the trash where it belongs

Does the job you want someone to do involve writing 1 page marketing nonsense, that follows standards that is never specified? No? Then stop making people write those to get the job. Letters of motivation should only be required for jobs where the skills you showcase by WRITING such a letter is relevant.

Throw the CV in the trash where it belongs

There is NO agreement on what a CV should contain. You can find people claiming that THEY know, and that you should ignore the thousands of others who say the exact same thing but disagree on what it should contain. You may be able to boil it down to "relevant skills" and "relevant experiences"... but now you are having the person who have no information about the job or the inner workings of the firm guess what skills and experiences are considered "relevant". So unless the job you want them to do involves blind guesswork, don't do that. Simply have a website that asks the candidates the relevant questions. Write down the very specific skills you want (Embedded C++, Javascript in React, Kotlin for Android etc) and ask the candidate if they have those. Simple yes/no questions. And for each of them, have a more general question (Low level programming, front end web development, Android development). Now, ask the candidate the general question, and if they say yes, ask them the specific questions that relates to that. Do the same for experience. A specific question could be "Do you have 1 year or more experience working with relational databases via C# ?" and a more general question could be "Do you have more than 1 year or more experience working with C#" or "Do you 1 year or more experience working with relational databases?". And yes, you can also have them write a paragraph about their extra experiences: "What hobby or work in other industries have you done that have help you develop as a worker?" "For how long did you do that?" This is essentially the specific bits you are interested in from the CV. And basically, anyone in the codeblr community could make this website in a few days, AND have it output files that is nicely formatted. Give them a few more days, and they will have a website for setting up the interview question website so it can be done quickly and efficiently.

You CANNOT know if a person will work well in the firm, or in the team

What to ask at interviews have been studied a lot. And we have data to at least make SOME statements. One of which is that it is IMPOSSIBLE to determine if a person will work well together with a team based on interviews. People simply do not act in a way at interviews where you can judge it. No amount of personality tests that con artists have sold your firm will help, and no, people cannot figure it out just by talking to someone (People however THINK they can. Which is worse that simply not being able to). The only way to find out is to hire people. We can do a middle ground technique and hire people for a trial Period. Which is NOT a guarantee that they will KEEP working well with the team... but it is MUCH better at predicting it than people who think they are somehow better at psychology than the entire scientific field of psychology. And yes, this costs money. But it costs LESS money than the alternative.

Either know what you want from a interview, and be able to test it, OR, throw the interview in the trash where it belongs

Interviews are THE most expensive part of hiring someone. And I have yet to be at a interview where ANYONE asked themselves "Why are we doing this?". I would say, in 8/10 cases, they are wasted. If you need someone to do design, architecture or development or other work where thinking in creative but structured ways are required, then you can gain some value. Either ask questions that 100% of candidates should be able to answer, and then dig into the "why" of their answer. For example, ask a software developer to name a software pattern they are relatively familiar with. Then ask them what that pattern does, and when it should be used. And when it should NOT be used. You can also give people homework to do before the interview. Again for programming, FizzBuzz is a great choice. Why? Because it is a solved problem, that is solved in a unsatisfying way. The problem is basically: "Make a program that takes a number to count up to as a input. If the number is divisible by 3, have the program output "Fizz", if it is divisible by 5, yell "Buzz". If it is both, yell "FizzBuzz"". Basically, you will quickly find the optimization that you never check for "FizzBuzz!". You just check for the two other things and output the relevant word. If both are true, then FizzBuzz will appear. So you make your 3 checks into 2 checks.... and then you are stuck. There IS no way to optimize further. Ask the candidate what extra information they would want to solve this test better. You can ask this at a interview or again, via a website that also gives the candidate the problem. Because fun fact, if you know if the program should be optimized for Speed (IE CPU efficiency) or how much space the program takes, or both, then you can actually make the program a LOT better. And knowing to ask the right questions when you are given requirement to your program IS a very great skill to check if the candidate have. You can also check the code. Was it easy to read? Is it easy to modify? Did they do anything cleaver like use linear programming to make it run faster? Did they do clever optimization tricks? (If they did that is good... but it DOES also mean they might pre-maturely optimize, which is a deadly deadly sin in software development.) I went through that in detail, because it showcases HOW to approach designing questions and tests for a candidate for a specific job.

And if you think it is too much work, or if you cannot come up with relevant questions and tests... THEN DO NOT DO INTERVIEWS. If hiring someone without an interview feels like a blind shot. You are correct. But it is LESS of a blind shot than hiring a candidate based on random and irrelevant skills. And it is a shit-ton cheaper.

A beginners guide to GIT: Part 5 - How to use GIT as a group.

Table of content: Part 1: What is GIT? Why should I care?

Part 2: Definitions of terms and concepts

Tumblr

A beginners guide to GIT: Part 2 - Concepts and terms

Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. <-------- You are here Part 3: How to

Part 3: How to learn GIT after (or instead of ) this guide.

Part 4: How to use GIT as 1 person

Tumblr

A beginners guide to GIT: Part 4 - How to use GIT as 1 person

Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. Part 3: How to learn GIT after (or in

Part 5: How to use GIT as a group.

Tumblr

A beginners guide to GIT: Part 5 - How to use GIT as a group.

Table of content: Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. Part 3: How to lea

For this, I will describe a workflow, called “feature branch workflow.” There are others that are simpler, and are sometimes better,  but I will describe one that always works, for any amount of people, and most likely is what your future workplace uses.. And yes, it involves branching (which sounds scary, but it is not so bad.)

Why? Well because of 2 goals we have that somewhat clash.

1: To use GIT in a way that is easy on ourselves and will give us all the benefits of GIT. This means committing often. Pretty much every time we have made a change, and we can compile.

2: We want to sync our work with our fellow workers. But this takes effort every time we do it because we might have made changes that clashes with changes someone else have made.

(Notice though that this is not a problem originating in GIT. This is a problem that comes from people working together on the same thing. GIT just makes it easy to spot the problems and describe them in an accurate way.)

We alleviate this by only syncing up when we have made a larger chunk of self contained work. Usually we use  the term "feature" for this. And they can be quite small (For example 4 commits, making a "Return to previous page" button ) or large (For example,  38 commits, which also used branches, to implement a GUI on top of the backend code we have made).

It is best to make features as small as you can, so that a feature branch does not end up being an entirely different sister project to the main branch.

The first thing we do is declare the main/master branch holy. Just like any branch, it must always compile, but now we add " May only have fully realized features". It must ALWAYS be ready to be shown to the customer/your boss/your adviser/your teacher.

So when we want to do some work, we coordinate it with our teammates so people are not working on the same thing, and thus wasting their time. ( This can be done with tickets, verbally at meetings, in group chats. Whichever fits your team )

Then we make a branch with its base at the tip of the main/master branch. We then do work, commit and push every commit onto that branch. This has all the benefits we had from working alone. We cannot get merge conflicts, as we are the only one working on this branch.

So let us show how this works! For this example I have set up a remote repository on bitbucket containing only a standard README that I have not written in at all., I then cloned it down in 2 different directories. Each of which I have opened with a console. This is how I will represent multiple people:

So first, we show off one person making a change, and the other getting it. So I add a main.c file in there, add it so it is staged for commit, and then commit it:

And if we write git status, we can see that we are 1 commit ahead of the remote repository:

We then push our commits to the remote repository:

The other user can now use git fetch (Which gets the latest information from the remote repository, but does not change anything):

We then pull the latest update from the remote repository with git pull:

This is the simple way to work. But of course, if we have changed the same file, we will get a merge conflict.

As we talked about, we will minimize those by using branches. So we will say that each of these two people now will work on a different feature. Each of which will be a function that prints something. And each will be in another c file, with a header. We will do this with branching. We want to make a branch, and then switch to it. Switching to branches is called “checkout”. We can do both in one step by checking out a branch that does not exist, with the option -b (You can as always read about checkout, by writing “git help checkout”)

git checkout -b My_Spiffy_Feature

When we then write git status, we can see that we are on the new branch:

I then add the new files. with the new function in, and we want test that they work by calling the function in main:

We then compile our program (which gets default name a.out) and run it:

It works! Great, time to commit. We add the new files, BUT NOT main.c or a.out . They were just for testing, and is otherwise not related to our feature.

And we then push to the remote repository:

As you can see, git complained, because while we have created our branch, we had not really configured it yet (Specifically, we never told git what branch this new branch should originate from from. We just created it out in the void). But GIT TELLS you what to do. So I simply wrote the recommended command, and bam, branch is working as we want it to

I update the new feature file, just so we have more than one commit. I add the changes, commit and push again:

Now that our feature is done, we want to merge the branch into the master branch.

To showcase something, I will first have the other person make a change to main, add, commit and push it:

The first person will now merge their spiffy new feature in. They do that by switching to the master branch with git checkout:

We see that we are behind 1 commit, so we pull.

But horror! Since we have the unstaged changes, we cannot pull, since we changed main.c to tests our new feature, AND the other person have changed main, those two cannot exist at the same time. So what do we do? Well, in this case, we are ok with our tiny test in main.c being lost. So we remove it like so:

Notice how EVERYTHING I did here, was just read what GIT said was the problem, then write git status, and do the actions that GIT tells me I can do, which solves the problem. Ok, now we have the latest update of the master branch. Time to merge our feature in:

This time I did not use the -m feature (Because I forgot) so I just used the external program to write the commit message.

And if we write git log, we can see every single one of the commits. Both in the branch, and in the master:

And if we want to get a bit of a graphical representation of what happened, we can use git log --graph:

Now, this is the simple way to do branching. You actually have full control over how exactly you want to merge your branch in. In this case, the two commits of the branch was added AFTER the commit on master. But we COULD have merged the branch in so that the two commits on the spiffy function was done BEFORE the changes on master. When you are still starting out, do not worry about this. But that is the workflow. You create a branch, you work on your feature in it, where you cannot get in the way of anyone else. When your feature is done, you merge it into the master. This way, the master was always ready to show to your teacher/boss, and did not have half implemented things that you would have to explain should be ignored at any point.

Half of the benefit of the feature branch workflow is that it minimizes the chance for merge conflicts. For them to happen, 1 group would have to go to the master branch and pull. AFTER they pulled, but before they managed to merge their branch in, another group must pull from master, and merged their feature in.

Unlikely.

But let us talk about merge conflicts.

Are those not horrible things that break everything?

No. Merge conflicts simply means GIT could not figure out how to merge something, and so a human will have to do it for it. GIT is nice, and shows you exactly where the problem is, and how to solve it. Let us create a merge conflict. The first person adds in the function that uses their new spiffy feature after the hello world prinf, stages the changes and commits them. But do not yet push

The other person creates 2 more printf statements in main, stages the changes for commit, and commits them:

Now we have 2 commits, that both changes main.c How should these two be merged? Should the spiffy feature be called before or after the newly added prinf lines? GIT cannot know this, and so will tell the humans to do it. And the job falls to whoever wanted to push in a change that creates the merge conflict. In our example, I will have the second person, who added the extra printf lines push first:

And now the first person with their spiffy feature pushes, and:

It fails... But we are fine. Nothing actually happened here. The remote is still fine, and we locally are still fine. But we have to figure out how to fix this. When in doubt, use git fetch to get all the info but change nothing, and then git status:

(By the way, I made an honest mistake here, and did not push the branch changes after I merged. But I am not really in trouble, because GIT saved me! :D) And as we can see, GIT is once again telling us what to do. Great!

And we are now at the place where we need to decide what to do. While you are still new, I recommend the default strategy. So we do as GIT tells us to:

And now, FINALLY, we have our merge error. But notice that we only got it this way, because we asked for it. So… what does that mean? Git status to the rescue once more!

As expected, the problem is in main.c Let us check out what is in that file:

We have our changes first, then a separation, and then the other changes. And fixing it is piss easy. We remove the lines GIT inserted to tell us where the conflict was, and put the code in order. WE decide if the spiffy feature should be put before, after or in the middle of the two printf statements. I decide to put them in the middle like so:

Merging the two versions together, is in of itself, a change to the code. So we will now do what we always do when we have made changes. Add the files that we changed, and make a commit, and then push:

We have now resolved the merge conflict.

Notice how the problems that we ran into were not GIT problems. We ran into issues that ALWAYS come up when multiple people are working on the same project. But GIT made it really clear what the issues were, and forced us to deal with them in a smart way! :D

I just downloaded a program, as a git repository. It allowed you to have it work in several different ways. Which was achieved by simply using "git checkout" to check out whatever branch you want. I love it. That is so smart!

That is a very neat idea!

If you like things like that you might want to look into VHDL ( I learned that... some years ago, but have not touched it since ) or Verilog.

They are... programming languages for making logic gate logic.

You combine that with an FPGA, which is essentially a whole lot of NAND gates ( Which as I said, can represent any logic gate system ), and then you can make hardware... via software.

And yes, these essentially do things like your idea. Things that would take a CPU aaaaages to do, can be done very very fast. So you "just" have normal C code, but if it runs onto one of the problems it have hardware for, it uses the hardware.

This is also how graphics cards work, or just floating point operations!

It is insanely cool! :D

What is half-adder and full-adder combinational circuits?

So this question came up in the codeblr discord server, and I thought I would share my answer here too :3

First, a combinational circuit simply means a circuit where the outputs only depends on its input. ( combinational means "Combine" as in, combining the inputs to give some output )

It is a bit like a pure function. It is opposed to circuits like latches which remembers 1 bit. Their output depends on their inputs AND their state.

These circuits can be shown via their logic gates, or truth tables. I will explain using only words and the circuits, but you can look up the truth tablet for each of the circuits I talk about to help understand.

Ok, so an in the case of electronics is a circuit made with logic gates ( I... assume you know what they are... Otherwise ask and I can explain them too ) that adds 2 binary numbers, each which have only 1 character. 

So one number is 1 or 0

And the other number is 1 or 0

So the possible outputs are are 0, 1 and 2.

Since you can only express from 0 to 1 with one binary number, and 0 to 3 with 2, we need to output 2 binary numbers to give the answer. So the output is 2 binary numbers

00 = 0

01 = 1

10 = 2

11 = 3 // This can never happen with a half adder. The max possible result is 2

Each character will be represented with a wire, and a wire is a 0 if it is low voltage (usually ground, or 0 volts) and a 1 if it is high voltage (Voltage depends. Can be 5 volts, 3.3, 12  or something else. )

BUT if you only use half adders, you can ONLY add 2 single character binary numbers together. Never more.

If you want to add more together, you need a full adder. This takes 3 single character binary numbers, and adds them and outputs a single 2 character number.

This means it have 3 inputs and 2 outputs.

We have 2 outputs because we need to give a result that is 0, 1, 2 or 3

Same binary as before, except now we CAN get a 11 (which is 3)

And we can chain full adders together to count as many inputs as we want.

So why ever use a half adder? Well, every logic gate cirquit can be made of NAND (Not and) gates, so we usually compare complexity in how many NAND gates it would take to make a circuit. More NAND gates needed means the circuit is slower and more expensive to make.

A half adder takes 5 NAND gates to make

A full adder takes 9 NAND gates.

So only use a full adder if you need one.

Geeks for Geeks have a page for each of the most normal basic cirquits:

GeeksforGeeks

Half Adder in Digital Logic - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, qu

I hope that made sense, and was useful :3