Просто не копируй это

Here are a few potential performance issues in the provided C++ code:

1. Reallocation of directions vector:
   The std::vector directions is being initialized inside the loop on each iteration. This causes memory allocation and deallocation, which can be avoided by moving the initialization outside the loop:

   const std::vector directions{ {1.f, 0.f}, {-1.f, 0.f}, {0.f, 1.f}, {0.f, -1.f} };
   while (!toVisit.empty()) 
   {
       ...
   }
   

2. Costly visited.find(nextPos) calls:
   Checking for nextPos in visited every time within the loop can be expensive depending on the size of visited. If visited is an unordered set, this is average O(1) but can degrade to O(n) in worst cases. If it is an ordered set, the lookup is O(log n). Consider if optimizing this lookup or how visited is structured can help improve performance (e.g., hashing Vector2 more efficiently).

3. Possible excessive dynamic memory allocation:
   The toVisit.push({nextPos, Vector2::DistanceSq(center, nextPos)}) creates a temporary object for nextPos and the calculated distance. Depending on the structure of toVisit, this might result in frequent memory allocations if it's dynamically growing.

4. Vector2::DistanceSq recalculations:
   You’re calculating the squared distance between center and nextPos in each iteration. If this calculation is redundant or repeated for the same points, you could store the result of Vector2::DistanceSq in a cache if the computation is expensive.

5. Inefficient toVisit container:
   If toVisit is a priority queue (like in A* or Dijkstra algorithms), using an inefficient data structure for this can slow down the overall algorithm. A heap-based priority queue might be more efficient for pushing and popping elements in such a pathfinding context.

Addressing these points should help reduce unnecessary overhead and improve the overall performance of your pathfinding code.

Магическая система типов Rust

Я не знаю, какой из текстов первичен. Но у вас (а также на видео), есть код:

#[derive(Debug)]
struct User {
    pub email: Email,
    pub password: Password,
}

А дальше идет user.password.clear(); , что также может быть опасно (если реализовать метод clear() и случайно сделать mut user). Лучше, в любом случае, поля инкапсулировать. Хотя да, согласен, и по моей ссылке этого нет, приходится додумывать.

Магическая система типов Rust

Пример из "Parse don't validate" подан неверно уже в источнике, не сказано, например, что password должен быть приватным. Видимо, первоисточник: Parse, Don't validate: An Effective Error Handling Strategy, там изложено правильно.