Dotfile Madness

Re:Dotfile Madness by delta_p_delta_x on Sunday October 23, 2022 @11:51PM (#33312774)

> Nobody should go out of their way to integrate with Windows APIs

  int writeConfigFile(ConfigFile file) {
  #if defined(_WIN32)
      // Windows-specific function
  #elif defined(__linux__)
      // Linux-specific function
  #elif defined(__APPLE__)
      // macOS-specific function

With modern C++, there's probably a way to do this in a nicer manner, and achieve runtime polymorphism with virtual functions or a lambda (function pointer) table.

As another sibling commenter wrote, .NET already has a platform-agnostic function to write to a `user program data` folder that nicely maps to the platform-specific directories. Other GC languages (Java, Go, etc) likely have similar abstractions.

As for scripting... A cross-platform project with scripts that also targets Windows should (in my opinion) have PowerShell `.ps1` scripts accompanying any `.sh` scripts. Better still, scripting should be done in a language that's truly platform-agnostic, like Python.

[ Parent | on HN ]

Re:Dotfile Madness by matheusmoreira on Sunday October 23, 2022 @11:58PM (#33312802)

> With modern C++, there's probably a way to do this in a nicer manner, and achieve runtime polymorphism with virtual functions or a lambda (function pointer) table.

You proved my point. Creating an #ifdef mess with polymorphism, virtual methods and indirection is the very definition of going out of one's way to support something that really doesn't need any support.

[ Parent | on HN ]

Re:Dotfile Madness by delta_p_delta_x on Monday October 24, 2022 @12:07AM (#33312842)

If a developer writing in C/C++ is targeting Windows, then bringing in `<windows.h>` (and associated headers) is almost guaranteed, especially if said developer wants to work with native APIs (unless said program will rely on MinGW/Cygwin/Msys2, which are arguably worse, since they drag in an entire Linux directory tree per application).

This is just part of the cost of developing cross-platform, and I'm sorry, but to me, dismissing this as 'going out of one's way' is just being sloppy.

[ Parent | on HN ]

Re:Dotfile Madness by matheusmoreira on Monday October 24, 2022 @12:24AM (#33312920)

Are the developers of "Unix-first software (such as `ssh`)" targeting Windows though? I don't think so. They don't deserve to be shamed for this stuff. They aren't "sloppy", Windows is lucky to get ports at all.

[ Parent | on HN ]

Re:Dotfile Madness by rollcat on Monday October 24, 2022 @08:48AM (#33315968)

> #elif defined(__linux__)

I felt a great disturbance in the source, as if hundreds of BSD users suddenly cried out in terror and were suddenly silenced.

[ Parent | on HN ]

Re:Dotfile Madness by 31b3r3t7 on Monday October 24, 2022 @02:57PM (#33320822)

No need for runtime polymorphism for this. The same binary won't be used in different operating systems. This is a classic example of misuse of C++ features just because they exist and a reason why I personally prefer programming in C. What I would do in a case like this is to have three source files each implementing the function for UNIX/Windows/Mac and the build system should take care of compiling the right one into the program depending on the OS.

[ Parent | on HN ]

Re:Dotfile Madness by delta_p_delta_x on Monday October 24, 2022 @09:43PM (#33325137)

This is a much better idea, actually. You're right that what I mentioned is a bad misuse of C++ features.

I initially did think of simply letting the build system handle it (CMake can do this excellently, as can Meson, probably) by simply choosing different source files for different target OSs, but when typing out the parent comment, I forgot about it in my train of thought.

Come to think of it, this is far more elegant.

[ Parent | on HN ]