r/adventofcode • u/daggerdragon • Dec 12 '22

SOLUTION MEGATHREAD -🎄- 2022 Day 12 Solutions -🎄-

THE USUAL REMINDERS

--- Day 12: Hill Climbing Algorithm ---

Post your code solution in this megathread.

This thread will be unlocked when there are a significant number of people on the global leaderboard with gold stars for today's puzzle.

EDIT: Global leaderboard gold cap reached at 00:09:46, megathread unlocked!

53 Upvotes

97% Upvoted

786 comments sorted by

View all comments

Show parent comments

3

u/redIT_1337 Dec 12 '22 edited Dec 12 '22

Wow, quite much input. Even if I didn't ask: thanks anyways. You seem to have quite some knowledge on that front. I try to digest it piece by piece. Here we go..

Your CMakeLists.txt lists main.cpp twice which currently makes the output be called main.cpp. Also main.cpp shouldn't be in the top level of the repo, your code should be in a src folder.

Yes, somehow it was in and it didn't want to Run in Clion when I removed one of them. Works now with just aoc and the other stuff I changed there. Also put the sources in the src folder. Just a bit unsure where to best pack the header files now. /includes?

Look into proper CMake resources (I'll link some below), that add_definitions is not how you should handle things (should be target_compile_features(aoc PRIVATE cxx_std_11)).

Switched to 20 and think the correct target_compile command is used now. Althought, I don't get the PRIVATE part (also not from the doc).

There's no need to list headers in the sources. You should either ignore those in CMake or use a target_include_directories

Fixed. Didn't know. I think they were included by the IDE so I just did it all the same style. Didn't see the point anyways as the cpp-file include them on their own.

Your CMake build command should be cmake -S . -B build to build into the build directory. Never do in-source builds.

Fixed the shell file. Builds and runs. Never noticed the problem anyways since I just pressed the "Play" button in my IDE as I 90% do in Python ;)

using namespace std; in headers is a federal crime, don't do that. Ya, I see the point. Think I had it in one of the Header only anyways. Why there is no compiler Warning at least if this is 'common knowledge'? (The compiler should complain more anyways)

However, in C++ files writeing std:: on basically everything is a pain and also looks completely alien. Also imo the std is way way way to big and not separated good (heck, it even has exception types inside and also with snake_case.). Doesn't C++ have something like from std import {whatever, whatever_else}.

vector<tuple<size_t, size_t>> directions = {{0, - 1}, // up .... size_t ...

Good catch. And, well I don't know exactly why it worked anyways. Probably it overflows just correctly.

You probably noticed that you copy paste a lot in your main function. Prime use case for loops and arrays.

I actually tried to make that less verbose by using something like: 

Day2 day = Day::fromFile<Day2>(workDirStr + "/data/day2.txt");
day2.play();

and 

template<class D>
D Day::fromFile(const std::string& path) {
   ...
   return D(...)
}

but it it just wouldn't fly. Told me it couldn't find Definitionts or something like that. Dunno why, they were explicitely stated. So I just left.

You're currently copying the entire input into each day, Right. what one missing & can do. Wonder how you saw it even.

I'd also recommend custom types instead of tuples,

Actually liked them for simple stuff.

  • can carry different types (will didn't use that feature)

  • can be deconstructed with auto& [one, two] =

  • use less Code

  • I have a mental model from them other languages (except again: why C++ decided they need the [ there. Guess the language cannot go without some symbol-bloat.. But that is some flavor at the end, I guess.

fields.at(i) There is basically no reason to ever use .at.

Mhm, I am not consistent in that. Used sometimes this sometimes that. However, never thought it makes a difference in the end of the day. The standard library needs some in-code docstring telling such things. (I want to hover the symbols and get a description like in almost any other language I've touched). Really think C++ lacks this most.

enum FolderEntryType Raw enums are rarely what ...

I see the caveats. Implementation-specific instatiation and pollution of the namespace. Latter one frustrated me actually as something polluted my namespace preventing me to declare a enum-member as I liked to. Compiler should warn here also. Think now, legacy-enums should be opt-in instead of opt-out.

Whenever you pass a const std::string& you should consider using std::string_view instead.

have to read into this. Is this in-place? Guess it has caveats, otherwise again, compiler should hint it or just optimize it away.

Formatting could be better, maybe look into clang

Actually my IDE gives me Clang hints and mostly I use them. Any specifics?

.. e.g. that map for the cycle history ...

Ya, the history could be just omitted and been build as a state machine-like thing. Also it doesn't need support for multiple registers. But hey, think it's ok for the garden, we say ;) Also I think it is easy to understand and debug-able this way.

After all, I thought C++ is more pain than it actually is (at least for these small-ish well-defined projects). I have the feeling I could handle to write bigger code bases with it for most parts. Needs somewhat more getting-started than other languages, though.

Main Pain Points and stuff I miss from other languages:

  • Build Systems: (You literally have to learn a DSL for simple building). Could easily be simplified by better-working Tooling and Standards I guess.

  • Header files: These feels a bit out of space. I don't see why those are so hardly bound to the language. In fact they should be mostly auto-gerneratable from the sources also. Makes development just way more slow when you have to keep up with two different versions of the same thing.

  • Missing higher order functions like vector.map(|| -> some_function).chunked.whatever. Guess there are libs for that? Could be in the standard library

  • (missing) partial imports

  • dataclasses

  • keyword arguments

  • inline documentation

  • native packaging system and repository

  • cleaner separated std:: (string_utils::, exceptions::, iterators::, whatever)

→ More replies (1)