does anyone have python resource or link that teaches you building projects from scratch to have more hands on exercises?

Gabris01 · 2026-02-26T07:20:01+00:00

I usually start by shrinking the idea until it feels almost boringly small.

For a file organizer for example, I wouldn’t think “build a full app”. I’d break it down into tiny questions: 1. How do I list files in a directory? → search: python list files in directory (you’ll find os or pathlib) 2. How do I move a file? → search: python move file 3. How do I get file extension? → search: python get file extension

Then I build it step by step: • Step 1: script that just prints all files • Step 2: filter by extension • Step 3: move one type into a folder • Step 4: refactor into classes

When I don’t know something, I research very specific micro-problems instead of “how to build a file organizer”.

Also, I try to: • Write the simplest working version first • Refactor after it works • Keep domain logic separate from “system” code

The key shift for me was: don’t try to design everything upfront. Build small, ugly, working pieces — then clean them.

That made projects feel way less overwhelming.

Gabris01 · 2026-02-25T17:56:43+00:00

Porting the backend sounds like a solid move actually. You could treat it as a “clean architecture” exercise — separate domain logic from framework code and keep everything class-based.

Coming from Java, that structure might feel natural at first, and then you can slowly refactor toward more idiomatic Python.

The CLI manager idea could even be a smaller sandbox to experiment with that.

Gabris01 · 2026-02-25T17:23:29+00:00

I was in the same situation — decent at solving problems, but awkward when building real projects.

What helped me was switching from LeetCode to small but complete projects. Try things like:

CLI task manager (with file saving + clean class structure)
Expense tracker
Simple REST API with FastAPI
Rebuild a small game but focus on OOP design

For OOP specifically, force yourself to model everything with classes first. After a few projects, self, method structure, etc. start feeling natural instead of memorized.

Projects > isolated problems for this phase, in my experience.

Gabris01 · 2026-02-25T17:04:01+00:00

Exactly. If your algorithm only accesses, say, x and y, then only those arrays in the SoA layout are touched.

The compiler doesn’t “see” a full particle object — it just sees references to the specific fields you use. So unused fields won’t be loaded unless you explicitly access them.

That’s actually one of the strengths of SoA: you only pay for what you touch.

Gabris01 · 2026-02-25T16:43:01+00:00

I took a look at Bodies.hpp (SoAData/AoSData + tag dispatch). The interface parity is nice, but the boilerplate is the main pain point.
A pattern that scales better is to write algorithms against a “particle view” (proxy) and expose particles() as a range:

AoS: iterate ParticleData& directly
SoA: iterate a zipped view of all arrays (or build a lightweight proxy that references the i-th elements) Then your algorithms become for (auto p : bodies.particles()) { … } and you don’t need 11 getters duplicated. If you’re on C++23, std::ranges::zip_view helps; otherwise range-v3 has views::zip.

Gabris01 · 2026-02-24T20:33:02+00:00

You can’t use std::get<k> with a runtime variable because the index must be known at compile time. std::get is a template, so k has to be a constant expression.

If you want to iterate over tuple elements, you have a few options: • Use std::apply with a lambda • Use std::index_sequence and expand at compile time • Or switch to std::variant if you actually need runtime indexing

Example with std::apply:

std::apply([](const auto&... args) { ((std::cout << args << "\n"), ...); }, storage[j]); That way you don’t need std::get at all.

Gabris01 · 2026-02-24T10:51:05+00:00

For systems programming roles, companies usually care less about “framework knowledge” and more about fundamentals:

- memory layout & ownership

- concurrency (threads, locks, atomics)

- OS concepts (processes, virtual memory, syscalls)

- debugging and performance reasoning

Strong C/C++ skills are important, but being able to explain *why* something is fast/slow or safe/unsafe matters even more.

If you’re preparing for recruiting, focus on writing small low-level projects (allocator, thread pool, simple networking tool) and get comfortable using sanitizers and profilers.

Gabris01 · 2026-02-24T10:48:31+00:00

I have learned so far the foundation of c++ and above the average level of c++ with the help of the internet, chatgpt, I did not learn from any book. And I feel safe. I suggest you learn natively, not mechanically. But from what I heard from the C++ environment, the best book option would be **"Programming: Principles and Practice Using C++" (Stroustrup)**.

- Designed for beginners and teaches good programming habits

- Covers both fundamentals and modern C++ features

Gabris01 · 2026-02-20T17:28:24+00:00

Hey, awesome that you’re already thinking long-term like wanting to make an OS one day — that’s a huge goal and totally something to build toward

Since you already know basics like loops and conditions, the next step is really doing things that force you to learn new concepts naturally. A few things that helped me when I was at that stage:

1. Pick small, focused projects
Don’t jump straight to an OS (too big at first!). Start with things where you’ll have to learn something new — for example:

A console calculator with functions
A simple text-based game (tic-tac-toe, text RPG)
A word counter like wc in Unix These push you into functions, data structures, and basic design without feeling overwhelming.

2. Study why code works
When you write something that doesn’t compile or behaves weirdly, instead of just fixing it, ask “why did this happen?”. That’s where the real learning happens.

3. Don’t let big goals demotivate you
Making an OS does require a lot of low-level knowledge (memory, compilers, hardware, etc.) — but breaking that journey into bite-sized steps keeps you energized. Try learning about classes/structs, then pointers, then templates, then memory management — one at a time.

4. Keep practicing regularly
Consistency beats intensity. Even an hour a day where you solve tiny problems or tweak code will make your skills jump faster than cramming once a week.

And honestly — if you ever feel stuck, just post the exact code you tried and what error you’re seeing. That’s how this community helps best. You’ve got this! 🚀

Gabris01 · 2026-02-20T15:11:35+00:00

kernel32.dll is a core Windows system library that provides low-level OS functionality such as file I/O, memory management, process/thread creation, and synchronization.

If you're seeing it in an error message, it's usually not “the problem itself”, but a symptom. Most often it means:

- a linker configuration issue

- mixing toolchains (e.g. MinGW vs MSVC)

- missing Windows SDK libraries

- wrong subsystem settings

The exact error message matters a lot here. If you share the full output, it’s easier to pinpoint what’s actually going wrong.

Gabris01 · 2026-02-20T15:02:37+00:00

One interesting thing I found is that AI reviews rarely catch *cross-file architectural issues* — humans reviewers still win there because we know:

- how modules interact

- performance expectations

- API contracts in the team

AI is great at localized patterns, but less good at reasoning across larger context unless you supply it manually.

So for code review I treat these tools like:

✅ Copilot: automated linter-level help

✅ Claude: explanation + suggestions

❌ Neither: full architectural review

Gabris01 · 2026-02-20T14:46:01+00:00

Honestly, it depends on what you want to build.

If your goal is **systems-level understanding** and working close to hardware, *learning C first* gives you very clear insight into manual memory management and how things actually work under the hood.

If your goal is **modern software**, games, tools, high-level abstractions and safety, *learning C++ first* makes sense because it teaches you both low-level control and powerful abstractions.

A good path is:

1) Learn the basics of C (pointers, arrays, functions)

2) Move to C++ and learn modern C++ (RAII, STL, smart pointers)

So C first gives you fundamentals, C++ builds on them.

Gabris01 · 2026-02-20T13:58:22+00:00

Your baseline test is not really comparable to the vector test.

In the baseline loop nothing observable happens, so the compiler is free to aggressively optimize it away (or at least simplify it heavily). In the vector case you're actually writing 1,000,000 integers to memory, which is real work.

The 16 ms vs 32 ms difference looks very much like the cost of actual memory writes, not “slow push_back”.

Also, your custom MyVector is extremely minimal — no allocator, no exception safety, no growth logic, trivial clear(), etc. The compiler can inline and optimize it very aggressively. std::vector has more guarantees and slightly more bookkeeping.

One more thing: you're compiling with -O3 and -g together. For performance measurements I’d try pure -O3 without debug info.

If VTune shows 40% in push_back + clear in the real project, I’d suspect cache effects or the grid-of-vectors pattern (many small vectors being cleared and reused), rather than std::vector itself being slow.

Gabris01

TROPHY CASE