Code maintenance

[LovelySanta]

Describe the issue (if no issue has been made)

Code maintenance of things Cherno did start but not finish or mensioned before but did not do in the code maintenance video.

PR impact (Make sure to add closing keywords)

List of related issues/PRs this will solve:

Impact	Issue/PR
Issues this solves	Part 1 of #140
Other PRs this solves	None

Proposed fix (Make sure you've read on how to contribute to Hazel)

A more detailed list can be found in #140 (comment)

• Convert the remaining smart pointers to Hazel wrappers
  • std::shared_ptr -> Hazel::Ref and std::make_shared -> Hazel::CreateRef
  • std::unique_ptr -> Hazel::Scope and std::make_unique -> Hazel::CreateScope
• Removing all DLL traces
  Removed all HAZEL_API macros
• Fixing include statements
  • All includes relative to Hazel/src
  • All external includes use <> instead of ""
• Use default (de)constructor instead of an empty one
• Removed the dedicated (duplicate) BIND_EVENT_FN in application
  Now uses the generic HZ_BIND_EVENT_FN instead
• Removed obsolete logging messages in glfw
• Removed obsolete YAML keys in PR template

Additional context

Tested in debug and release, the rest of the code maintenace can be found in #140 (comment).

[CleverSource]

When will this be merged?

[LovelySanta]

When will this be merged?

I think tomorrow, or after cherno's next vid/upload to github. However, I found some small things that still requires attention before I can merge it: #140 (comment)

[LovelySanta]

Should LovelySanta#47 be merged into this?

[CleverSource]

I don't think it should be merged into this.

[LovelySanta]

I don't think it should be merged into this.

The reason I did it lije this, only Window.cpp includes the WindowsWindow, so in that file we can add/remove the obsolete classes when they are not required. This could even work for the different renderAPI's, for example exclude DirectX in macOS...

Any particular reason why you're against it @CleverSource ? I can see how it might require a seperate PR instead...

[CleverSource]

It's a good PR, but it doesn't feel very maintenance like and seeing as this PR is meant for maintenance I don't see why a PR unrelated should be merged with this.

While I do think the other PR should be implemented in some way, I don't think it should be added with this PR.

[LovelySanta]

Removed LovelySanta#47 from the TODO list. I'm waiting till cherno pushes his code before I'll update this and merge it.

[CleverSource]

Will this be merged now?

[LovelySanta]

Will this be merged now?

There are still some things to do, see #140, such as removing the OpenGL casting in the 3D renderer...

[LovelySanta]

Will this be merged now?

Now everything is implemented. I want to have anther look in the weekend and I plan on merging it on monday if everything looks alright.

[Puddlestomper]

Seems mostly good to merge. Only some minor things that we should clear up.

One other thing that I can think of that we might want to include, seeing as we have the platform detection now, is the include guards for the API-specific files depending on platform. The Windows* files would only be on Windows and the OpenGL* files can probably work on both Windows and Linux. Do you think we should do that? And, if so, should it be part of this PR?

[LovelySanta]

One other thing that I can think of that we might want to include, seeing as we have the platform detection now, is the include guards for the API-specific files depending on platform. The Windows* files would only be on Windows and the OpenGL* files can probably work on both Windows and Linux. Do you think we should do that? And, if so, should it be part of this PR?

That is exactly what I asked some days ago: #165 (comment).

The only place Windows* files are included are within the Window and Input class for the WindowsWindow and WindowsInput respectively. By adding a create function to them (as done in LovelySanta#47), we can use the include guards to include the headers (if needed) and use them to return the correct implementation.

I agree with the reply from CleverSource #165 (comment) on the matter: It is a good PR, but not really maintenance, it should have its own PR into Hazel instead.

So I think this is indeed a nice suggestion, but also outside the scope of this PR?

[CleverSource]

It most likely is outside the scope of this PR to be quite honest.

[beewyka819]

I know this is an old PR that was merged over a year ago, but Cherno mentioned in the Smart pointer episode (20 minutes in) that the spdlog::loggers should remain in std::shared_ptrs instead of Hazel Refs since spdlog::loggers aren't Hazel assets. Felt like I should just bring that up since the latest master still has them as Refs.

[LovelySanta]

I do remember that yes, but as long as it is just a wrapper around shared ptrs, this is equivalent. When we implement our own ref system, it has to change indeed.