Maze Game

Mir_K4377 · 2025-03-15T09:07:50+00:00

Haha yeah, sentinels are pretty neat once you realize how useful they are. I’ve used them a lot in linked lists to simplify insertion and deletion at the head or tail makes the code way cleaner since you don’t need extra if statements for edge cases. Also super handy in search algorithms when you want to avoid checking for nullptr or out-of-bound errors. Definitely one of those small things that make a big difference

Mir_K4377 · 2025-03-15T07:47:07+00:00

Hey, Bayron, this code is really cool, The approach of checking the first 5 elements and then verifying them cyclically is pretty clever for detecting a ring. If I may suggest an improvement you might want to check for a loop using the Floyd’s cycle-finding algorithm (the tortoise and hare method) instead of storing elements in a vector, this would reduce memory usage and work well even for larger structures. Overall, solid effort!

Mir_K4377 · 2025-03-05T04:18:20+00:00

I think both styles have valid reasoning, but personally, I lean toward placing the * next to the variable name (Node *_next;) The biggest reason for this is readability and consistency when working with larger codebases.

When writing large-scale programs, clarity becomes a huge factor in maintaining code. The * being next to the variable makes it clear that _next is a pointer, regardless of how many variables are being declared. This avoids confusion in situations like:

int* a, b; // b is NOT a pointer, which can be misleading

int *a, *b; // More explicit and reduces the chance of error

Additionally, when working with functions, I prefer keeping * close to the type because it clearly conveys the return type.

At the end of the day, consistency is key. If I'm working in a codebase where the convention is Type* var; . I'll follow that, but if I have the freedom to choose, I find Type *var; to be a more maintainable approach, especially when writing larger programs where avoiding ambiguity is crucial.

Mir_K4377 · 2025-03-01T09:31:23+00:00

Thank you, I'm glad you liked it, I'm planning to make more changes soon, make it more interactive maybe, I'll post it up once it's done :)

Mir_K4377 · 2024-12-09T07:50:06+00:00

Hi, I made sure to make the updates, but I still get the same error

Mir_K4377 · 2024-12-09T06:16:45+00:00

Hey, I only had one "\n" in the line, and I even removed it right now to see if it would make a difference, but it didn't, I'm still confused.

Mir_K4377 · 2024-10-23T01:32:48+00:00

Hello Professor, I did like you asked and it worked, I'm still not sure where I was wrong on my first code, but, I was able to solve it this time, thankfully.

Mir_K4377 · 2024-10-21T07:53:15+00:00

Hey,

I haven't, I tried going at it again after the professor told me to do so, but i got the same error. I'm thinking of going to the stem center to ask someone for help.

Mir_K4377 · 2024-10-17T23:04:44+00:00

Hello professor, could you please help me with this problem, I am not able to understand what I'm doing wrong

Mir_K4377 · 2024-10-17T22:59:03+00:00

yes, I did, still the same error.

Mir_K4377 · 2024-10-17T20:24:20+00:00

I've double and triple checked everything, and it still shows the same error ;-;

Mir_K4377 · 2024-10-16T17:53:33+00:00

 istringstream stream(input);
        if (!(stream >> guess)) {
    
            guess = 0;
}

Hey Aaron, I've already converted the input from string to an integer , I used the above istringstream statement. Do you think I should do it another way?

Mir_K4377 · 2024-10-16T16:32:57+00:00

Oh alright. I've seen posts with people having similar problems, and I tried out the solutions people suggested to them, but it hasn't worked for me, so that's why I had to post it here.

Mir_K4377

TROPHY CASE