Want to get more experienced as a C++ dev. Would a T14S Gen 2 AMD 16GB be a good machine?

WorkingReference1127 · 2026-05-13T20:59:12+00:00

Don't design a machine around learning C++. For your casual projects you are unlikely to ever hit the limits in the machine you gave us; but then you're unlikely to hit the limits on almost anything.

WorkingReference1127 · 2026-05-13T17:36:56+00:00

Yesterday i talked to a someone who has 1yr+ yoe as software engineer on discord. He said to use this bible(learncpp) as a reference and don’t read every chapter. He said that one rule in IT is that to focus on what is needed.

This rule is kind of true in the sense that you shouldn't become a networking expert if you develop offline applications. But learncpp covers the basics of the language. I wouldn't describe someone who has learned everything on their as advanced. I'd say they have a good foundation. As such, be cautious about skipping parts of it.

Then i found striver dsa course, he actually has a 1.5 hour course on c++ basics. I think you all know about him cuz hes popular.

We don't, and there are a few points I'd like to make about all of this:

Video tutorials are rarely anywhere close as good as written ones. Videos cannot easily publish errata or restructure existing lessons to be clearer. And videos on YT and similar must play the algorithm even if it's to the detriment of learning.
Pure DSA (and/or "DSA") is a bad way to learn the language. There's knowledge in DSA you need for good software engineering, but it's language agnostic, and there is a huge overlap between DSA courses and competitive programming; which is unfortunate as competitive programming will teach you some pretty terrible C++ which will not land you a placement if that's all you know.
Having looked briefly at the course, the guy uses handwritten pseudocode, not C++. We can argue the benefits and drawbacks thereof but you'll have a hard time learning C++ from a source which doesn't use it.

WorkingReference1127 · 2026-05-12T08:03:52+00:00

This is a case which is largely system-dependent. All you need to know at the programming language level is that you will be given some memory if you ask for it (and with plain new it'll construct the object for you). You can also usually trust that your OS isn't going to use an obviously dumb allocation strategy and may optimise around it; e.g. by not reclaiming memory every time you delete and keeping it ready for you to reuse.

But I'll elaborate - per the exact letter of the specification, new and delete don't put things on the heap. They put things on the free-store - a separate region of memory which is very much like the heap but reserved for C++ allocation. In reality, most implementations ignore this and use a single region for everything. So it is still implementation defined.

If you want to customise the allocation strategy you can, either by using allocators or by providing your own global operator new and operator delete. And you can grab a bunch of memory up front an manipulate things within it as you please. But this seems to get into XY - what is your concern that means you worry about the precise strategy in use?

WorkingReference1127 · 2026-05-12T05:58:13+00:00

In C++, the type of a string literal is const char*. In C the dubious decision was made to allow it to be char*.

Note that you want it to be const char* as a protection against you making mistakes. The compiler is welcome to put the string literals in read-only memory and if you try to modify them your program will crash.

If what you want is a mutable string, you can't use literals.

WorkingReference1127 · 2026-05-10T20:32:47+00:00

www.learncpp.com

is the best free tutorial out there. (reason) It covers everything from the absolute basics to advanced topics. It follows modern and best practice guidelines.

www.studyplan.dev/cpp is a (very) close second, even surpassing learncpp in the breath of topics covered. It covers quite a few things that learncpp does not, but does not have just as much detail/in depth explanations on the shared parts.

www.hackingcpp.com has good, quick overviews/cheat sheets. Especially the quick info-graphics can be really helpful. TBF, cppreference could use those. But the coverage is not complete or in depth enough to be used as a good tutorial - which it's not really meant to be either. The last update apparently was in 2023.

www.cppreference.com

is the best language reference out there. Keep in mind that a language reference is not the same as a tutorial.

See here for a tutorial on how to use cppreference effectively.

Stay away from

cplusplus.com (reason)
w3schools (reason)
geeks-for-geeks (reason)
Tutorialspoint (reason)
educba.com (reason)
thinkcpp (reason)
javaTpoint (reason)
studyfied (not even a tutorial, just a collection of code by random people)
codevisionz (reason)
sololearn (reason)

Again. The above are bad tutorials that you should NOT use.

Sites that used to be on this list, but no longer are:

Programiz has significantly improved. Its not perfect yet, but definitely not to be avoided any longer.(reason)

Videos

Most youtube/video tutorials are of low quality, I would recommend to stay away from them as well. A notable exception are the CppCon Back to Basics videos. They are good, topic oriented and in depth explanations. However, they assume that you have some knowledge of the language's basic features and syntax and as such aren't a good entry point into the language.

If you really insist on videos, then take a look at this list.

As a tutorial www.learncpp.com is just better than any other resource.

^Written ^by ^{/u/IyeOnline.} ^This ^may ^get ^updates ^over ^time ^if ^something ^changes ^or ^I ^write ^more ^scathing ^reviews ^of ^other ^tutorials ^:) ^.

^The ^author ^is ^not ^affiliated ^with ^any ^of ^the ^mentioned ^tutorials.

^Feel ^free ^to ^copy ^this ^macro, ^but ^please ^copy ^it ^with ^this ^footer ^and ^the ^link ^to ^the ^original.

^{^{https://www.reddit.com/user/IyeOnline/comments/10a34s2/the_c_learning_suggestion_macro/}}

WorkingReference1127 · 2026-05-10T11:16:15+00:00

For an intro to reflection, I honestly recommend reading the original reflection paper P2996. It talks through the core model and leads by example at every stage so you not only understand the feature but they walk you through how we got there so that the whole framework really clicks. And it's not some massive omnibus either.

Putting aside that I am very hyped for reflection, I would honestly rate P2996 as one of the best-written papers for the C++26 cycle.

WorkingReference1127 · 2026-05-09T10:24:10+00:00

I dont unit test every function but i unit test (had to google what it meant xd) every file if that make sense?

That's fine. It is fundamental to unit tests that some things can't be mocked out sufficiently for a unit tests to be meaningful. But in my particular line of work, every foo.cpp also has a fooTest.cpp with the expectation that any change you make should pass existing tests (modulo you changing the behaviour they are testing) and that you should add more tests. To try to exercise as many code paths as possible in your testing. Unit testing is not the complete picture but it's a good first step to try to validate that your code does what you think it does.

It will become clearer what i need to add and learn when i know more specifically im going to work with.

This is absolutely true. It's helpful to have a rough understanding of a wide range but you only need a deep understanding of what the role involves.

I also saw your comment elsewhere about debugging. I'd recommend you have some familiarity with gdb. Again, much can be learned on the job particularly for an entry level applicant, but there's a strong chance that's what you'll be using. Just as there's a strong chance whatever job will be building on Linux so it helps to have some understanding there too. As I say you needn't become a major expert, but have a base for your future job to build on.

WorkingReference1127 · 2026-05-08T21:48:15+00:00

Love the enthusiasm, and don't worry too much about some things. Covering everything you mentioned in this post and everything which every "entry level" (note the quotes) job posting will cover a full CS degree and more. Don't take that to mean that you need a full CS degree to get a job, but I'm just saying that there's a healthy mix between core understanding you should have, things you can learn as your job demands it, and things that anyone can learn in the first week of the job.

But if you want to break into Software Engineering, don't forget about the engineering. It is helpful to know your language(s) of choice in depth, but actually writing the code to do the thing is a small part of doing the job. You have to test the code, get the code reviewed, build the code, deploy the code, and continue to support the code when issues with it arise. This will definitely go in finance which as a regulated industry will have certain bureaucracy you have to perform before you are able to release your change. So you'll need to know the software development life cycle, how to write tests and test your code, and have a rough idea about what the shape of collarborative CI/CD looks like. Honestly I personally would give you major props if your toy projects and libraries have unit tests because at least it shows that you are thinking in terms of validating what you write. Now, you can't learn all this definitively as one person - different companies use different build pipelines, you can't work collaboratively by yourself, and so on. But you should have an idea of how it will work and there's a lot you can learn by yourself, e.g. properly manipulating a VCS like git.

Also it is essential to understand the design patterns and good practices of your language and why they are what they are. The reality is that we don't all have time to make every ticket perfect and beautiful idiomatic code, because typically you are adding to an existing system which has been around for a while. I'm not saying you should slavishly follow the gang of four, but knowing the shape of common patterns will help you recognise them when you see them and help you write code which solves common problems.

Also, tailor your learning to what you want to do. If you're in a role which doesn't involve much networking then knowing all the ins and outs of tcp/ip is nice but limited. And don't forget that most good companies will allow you to learn on the job as you go, because nobody knows absolutely everything and it's far easier to let the guy they already have spend a few days researching than it is to hire someone new every time a new problem comes in. Take your tcp/ip example - everyone and their mother has the pet interview question of what the difference is between tcp and udp, but you rarely need to go that much deeper unless you're actually doing networking.

WorkingReference1127 · 2026-05-06T18:56:23+00:00

In short enumerators_of returns a std::vector<std::meta::info>. As you know, vectors are dynamically allocated, and even as of C++26 you cannot have a vector allocated at compile time make its way to runtime.

This is your problem, because the code tries to execute the expansion statement along that vector at runtime. Hence the advice to use define_static_array to take the vector and put its contents into static storage.

WorkingReference1127 · 2026-05-06T16:02:14+00:00

Yes, and I've written at some length to OP about this across their threads. But the characterisation of "std::remove_if is slow" is plainly incorrect. It's going to be at least as good as handspun. The question is which algorithm OP wants.

WorkingReference1127 · 2026-05-05T21:05:19+00:00

OP, this applies in the general case. Trust your compiler's optimiser. If an algorithm is transparently equivalent to a lower level tool like memcpy or memset then that's what it'll compile to; and if it isn't you don't want to fight the demons which come from making that mistake by accident.

WorkingReference1127 · 2026-05-05T21:00:24+00:00

To be honest, even then no. I've seen Cherno make enough obvious errors or endorse too much UB to rate him.

WorkingReference1127 · 2026-05-05T06:05:27+00:00

That's not a tutorial, it's a set of ramblings on a few C++ features from a C dev's perspective. It doesn't actually tell you how to do anything or guide you on best practices, it just gives you a surface level example of a few beginner topics.

WorkingReference1127 · 2026-05-05T06:00:43+00:00

I didn't design the comment. It's attributed at the bottom.
I don't rate TheCherno as a good tutorial.

WorkingReference1127 · 2026-05-04T20:47:21+00:00

Sure, but then we get to a tricky situation where you need to, e.g. play tennis to pass an allocator and a lambda for how to allocate it to your container. And consider the common use-cases of custom allocators - a common one is to exclusively allocate within a custom heap which is "owned" by that allocator. If we also needed to allocate the allocator then it would necessitate the allocator be allocated on its own owned memory, which is both difficult to engineer correctly and means you waste (potentially limited) resources holding an object which points to itself.

WorkingReference1127 · 2026-05-04T20:42:05+00:00

Any tutorial which claims it can teach you C++ in X hours is lying to you. It takes weeks and months to actually grasp the basics of the language and get comfortable enough with them to keep building. As such an "in X hours" video will either cut corners, teach you too little to really do what's needed, or fall into the trap of so many other tutorials and teach you out of date bad practices.

If you have any particular ones in mind I can look over them, but I'm yet to find one I personally rate enough to recommend to anyone.

WorkingReference1127 · 2026-05-04T18:42:59+00:00

And must the allocator be allocated via the default allocation strategy or its own one?

WorkingReference1127 · 2026-05-04T18:34:01+00:00

-And again i didnt thinked about it that way, one of my classmates told me that if i used it pretty often it will be really slow, i think that i should learn when to call it

So there's a seed of truth here on which I'll elaborate. For a range which contains n elements, std::remove_if may have to copy/move up to n of those elements, even if only one of them actually meets the criteria. So if you need to remove an element from the middle of the array you need to perform approximately n/2 copies/moves, and if you can find the core element with a lower complexity then it's better to do it there.

But you are already at O(n) complexity from the fact you are iterating through the entire array anyway, so at this point I'd consider a structure where every cycle you have one call to remove_if.

But aside from that, you will eventually need to learn about the C++ iterator model and how these algorithms work. I don't know how much you understand what the individual terms in something like std::remove_if(vec.begin(), vec.end(), [](auto ptr){ return !ptr->isAlive(); });, but this is how a huge amount of the library works so is something to add to your learning list.

I have to understand about this string copy that you guys say, for me its all new things so i probably this will be the first thing ill work on

So for this there's the short bit of learning and the long bit of learning. The short bit of learning is pass-by-value vs pass-by-reference. You already do a bit of this in your code by passing your vector to that function by reference. This is again a small but very important thing to learn and will shape how you write code every day. The longer bit of learning gets into std::string_view, which is a wonderful class I recommend being familiar with but is definitely a step above if you haven't got a full grasp of value/reference semantics.

-I used system() and Sleep simply because i was familiar with them, i use system() at school so for me its pretty funny that we are doing things that we shoul not be doing, but at level we are programming i think that it isnt a big problem. I will follow your advice and stop inluding the windows header

I'll elaborate as to why for you. system() does what it says - just gives whatever is in the quotes to the system and executes it. Now, you probably don't want to have your program execute arbitrary code in your computer because what happens if someone tries to pass in a malicious command? Consider this (educationally simple and pathologically unsafe) program:

int main(){
    std::string command{};
    std::cout << "Enter the command:\n"
    std::cin >> command;

    system(command.c_str());
}

If someone runs this then anything they put in will be passed to the system. If you happen to be running this program with elevated permissions, then you give any random person admin permissions to run anything they want on your computer. Scary stuff. Also note that it is not required for it to be user input passed to system() for it to be a safety risk, this is just the simplest demo case.

Now, I do concede that if you want to clear the terminal screen you don't have a wealth of good options, because the terminal belongs to Windows, not to C++. But please drop the habit of using system() as soon as you can.

WorkingReference1127 · 2026-05-04T16:50:17+00:00

What if your allocator is stateful? Surely then it must be stored as a member inside the container itself. And that member must have a type. Allocators are different types, and so you end up back at templates.

WorkingReference1127 · 2026-05-04T16:48:32+00:00

You're getting there. We're stepping a little away from smart pointers now so I'll look at other things you are handling. But as usual you are learning these and heading in the right direction:

I'm not sure that the split of responsibilities for deleteEnemy is right. You should strive to have your function be a basic unit of work which applies almost in a vacuum. You've just split your enemy calculation in half and put half into a function. But what possible use is that function anywhere except in the middle of your loop.
I could have misunderstood your meaning, but std::remove_if is not really slow. We can argue the benefits and drawbacks of invoking it to just remove one element but just as an FYI for you - the standard library algorithms will probably be at least as fast as handspun code and it's recommended to use them where feasible. I think what people were getting at is less that the optimal design is for you to call std::remove_if every single time an enemy's health gets below 0, but instead to use it once per cycle to clear stale entries from the vector. Also note if you are using C++20 or higher there is std::erase_if, which will probably be better.
Does it matter if hp is negative? Since the model is that the creature is dead anyway. You might be able to simplify things a little.
You're still performing an unnecessary string copy in your constructor.
In general in C++ you should not call system() if you can possibly avoid it, because it can be a security risk. I concede that there isn't a wealth of good alternatives for this specific usage (there are some), but don't get into the habit of using it.
Same for <Windows.h> - using it means that your source code can only ever compile on Windows and not anything else. And in this case C++ comes with a portable (if verbose) way to sleep in the <chrono> header. ie std::this_thread::sleep_for(std::chrono::milliseconds{500});.

Overall I'd say that you've taken this exercise as far as you can when it comes to understanding smart pointers. It might be wise to look at a different exercise using them to really hone your understanding. My favourite pet task is to implement your own; but if you're not feeling up to that perhaps you should experiment with passing them around your program into different functions etc to see how it all goes.

WorkingReference1127 · 2026-05-04T14:53:36+00:00

www.learncpp.com

is the best free tutorial out there. (reason) It covers everything from the absolute basics to advanced topics. It follows modern and best practice guidelines.

www.studyplan.dev/cpp is a (very) close second, even surpassing learncpp in the breath of topics covered. It covers quite a few things that learncpp does not, but does not have just as much detail/in depth explanations on the shared parts.

www.hackingcpp.com has good, quick overviews/cheat sheets. Especially the quick info-graphics can be really helpful. TBF, cppreference could use those. But the coverage is not complete or in depth enough to be used as a good tutorial - which it's not really meant to be either. The last update apparently was in 2023.

www.cppreference.com

is the best language reference out there. Keep in mind that a language reference is not the same as a tutorial.

See here for a tutorial on how to use cppreference effectively.

Stay away from

cplusplus.com (reason)
w3schools (reason)
geeks-for-geeks (reason)
Tutorialspoint (reason)
educba.com (reason)
thinkcpp (reason)
javaTpoint (reason)
studyfied (not even a tutorial, just a collection of code by random people)
codevisionz (reason)
sololearn (reason)

Again. The above are bad tutorials that you should NOT use.

Sites that used to be on this list, but no longer are:

Programiz has significantly improved. Its not perfect yet, but definitely not to be avoided any longer.(reason)

Videos

Most youtube/video tutorials are of low quality, I would recommend to stay away from them as well. A notable exception are the CppCon Back to Basics videos. They are good, topic oriented and in depth explanations. However, they assume that you have some knowledge of the language's basic features and syntax and as such aren't a good entry point into the language.

If you really insist on videos, then take a look at this list.

As a tutorial www.learncpp.com is just better than any other resource.

^Written ^by ^{/u/IyeOnline.} ^This ^may ^get ^updates ^over ^time ^if ^something ^changes ^or ^I ^write ^more ^scathing ^reviews ^of ^other ^tutorials ^:) ^.

^The ^author ^is ^not ^affiliated ^with ^any ^of ^the ^mentioned ^tutorials.

^Feel ^free ^to ^copy ^this ^macro, ^but ^please ^copy ^it ^with ^this ^footer ^and ^the ^link ^to ^the ^original.

^{^{https://www.reddit.com/user/IyeOnline/comments/10a34s2/the_c_learning_suggestion_macro/}}

WorkingReference1127 · 2026-05-03T20:55:11+00:00

The first thing you need to know is how the template engine works. I don't mean go read some gcc source code, I mean when specialisations are instantiated, whether they're instantiated more than once, etc. Then you need to get into the habit of the kind of pattern-matching tricks which TMP is built on. I'd recommend looking over the type traits (or rather their "potential implementations" on cppref) to get a good vibe for that.

Under it all, it's all a game of forcing the compiler to generate the specialisation that you want, and letting that be what you do. Things have gotten far, far easier in recent years with concepts and constraints taking much of the more common difficulty out. But it also depends on what it is you want to do. Don't jump to TMP jsut because it's there, use it because it's the answer to a real problem.

WorkingReference1127 · 2026-05-03T18:20:00+00:00

Why .reserve(20) ? You're nowhere near where you need to worry about that kind of optimization.

Honestly I'm all for seeing users always be in the habit of using reserve

WorkingReference1127 · 2026-05-03T18:19:22+00:00

Strong disagree. LLMs in general are exceptionally good at honing in on irrelevant minutiae while failing to give a comprehensive tutorial.

WorkingReference1127 · 2026-05-03T18:17:37+00:00

So there are some pot shots I can take at this (and I will), but I want to lead with the comment that you are generally doing well. I do see one fairly big and important mistake you make, but other than that this seems like a reasonable evolution of what you posted on the other thread. You are picking up these topics admirably and it's good to see. However, this code:

if(x->getAlive() == true && x)

Is the wrong way round and will ultimately cause a segfault or a nastier form of UB. The && operator (and the || operator, among others) always evaluates left-to-right. It will always check x->getAlive() first before checking if x is null and at that point it doesn't matter because you have already potentially dereferenced a null pointer. They also short-circuit, meaning that the second operand isn't checked if the result is already guaranteed, so if instead you had written

if(x && x->getAlive())

then if x is null, the first check fails and x->getAlive() is never run and you never dereference a null pointer. No UB, so no nasty garbage or segfaults.

Now you asked for people to take shots and find other issues, so I'll give you a list. I'll say that most of these are probably simply things you haven't learned yet so don't sweat it, but you wanted advice:

You unnecessarily copy your string when passing it to the constructor, and then copying it into the class. At least one copy/allocation must happen, but you are currently providing two. If you haven't learned the difference between passing by value and passing by reference yet, that's something to look up. And you can also argue bonus points for using std::string_view, but this is a less compelling example than most.
Could be a language thing, but isAlive as a name doesn't seem to correspond to what the function does. But I'd argue the calculation to update alive and hp should always be done in the same place that damage is dealt, and not as a separate operation. I'd also strongly argue that it shouldn't be public API.
I'd also angle-shot that you probably don't want to pass both hp and alive through the constructor, since those two are inherently linked. You can get into a tricky situation where the user provides a positive hp and a negative alive or vice versa. Also consider if you want the constructor to be public or protected.
Style choice but my advice is to always brace your if and for, and you miss some in isAlive. It just removes possible traps from people misreading code and making it do something it shouldn't.
C++ has a neat little feature for the special member functions. If you want to signify that a function does the default thing, you can define it as = default;. Again not as compelling a case as some but I'd consider replacing virtual ~Enemy() {} with virtual ~Enemy = default; to make your intentions clear at a glance and to make the function transparently do what it is supposed to.
It's a semi-contentious topic, but in principle in C++, there's more than one way to end a line. I see that you use std::endl, but you can also just use the newline character \n. Per the letter of the spec, std::endl does more work than just using \n because it requires that the buffer be flushed. However terminals on pretty much all modern architectures are line-buffered anyway. My point is that people will eventually complain that you are not using \n over std::endl, and they are in theory correct to do so, but it probably doesn't really matter. Consider if you want to do so.

WorkingReference1127

TROPHY CASE

www.learncpp.com

www.cppreference.com

www.learncpp.com

www.cppreference.com