Create DLL in Adept: make the init function and deinit function optional

[ghost]

For example, my SampleLibrary.adept is like this:

external func Addition(x double, y double) double = x + y

external func Subtraction(x double, y double) double = x - y

external func Multiplication(x double, y double) double = x * y

external func Division(x double, y double) double = x / y

Something like this is totally fine with other languages. The fact is, I have only seen the init function and deinit function being used in C++. Other languages I have worked with, e.g., FreeBASIC, are totally fine without the init function and deinit function. As I recall, even in C++, these functions are optional.

Currently, this is what I see when I tried to compile SampleLibrary.adept with adept --dylib SampleLibrary.adept:

Expected init function name and deinit function name after '--dylib' flag
  USAGE: --dylib <init function name> <deinit function name>

[IsaacShelton]

I did some research and I think it might be possible to handle this automatically by generating a DllMain function, so that they happen automatically when the DLL is loaded/unloaded.

That way like you described, you wouldn't need to specify an initialization/deinititialization function.

For a temporary solution, you can create initialization and deinitialization functions, and just never call them:

pragma dylib my_library_init my_library_deinit

external func my_library_init(){
    print("Initialize called")
}

external func my_library_deinit(){
    print("Deinitialize called")
}

external func Addition(x double, y double) double = x + y

external func Subtraction(x double, y double) double = x - y

external func Multiplication(x double, y double) double = x * y

external func Division(x double, y double) double = x / y

Or you can also manually define DllMain to automatically initialize/deinitialize if you need global/static variables.

external stdcall DllMain(hinstDLL HINSTANCE, fdwReason DWORD, lpReserved lpReserved) BOOL {
    switch fdwReason {
    case DLL_PROCESS_ATTACH:
        // Initialize once for each new process.
        // Return FALSE to fail DLL load.
        my_library_init()
    case DLL_THREAD_ATTACH:
        // Do thread-specific initialization.
    case DLL_THREAD_DETACH:
        // Do thread-specific cleanup.
    case DLL_PROCESS_DETACH:
        // Perform any necessary cleanup.
        my_library_deinit()
    }
    
    return TRUE  // Successful DLL_PROCESS_ATTACH.
}

[ghost]

As far as I know, Linux shared library doesn't need this. I can create a DLL without having to define init function and deinit function on Windows with MinGW GCC. Init function, deinit function, and DllMain are all optional. They are giving you more control, but they are completely optional. Why are you forcing me to define init function and deinit function?

Btw, is Adept able to make shared library on Linux?

[IsaacShelton]

Init and deinit functions are necessary to initialize global/static variables.

It's easy to accidentally rely on global/static variables and not realize it.

Although you can just not call them if you are absolutely sure.

Ideally like you said, you wouldn't need to declare them. Currently though, Adept does not auto-generate the boilerplate yet to allow you to skip it.

It looks like on linux they have __attribute__ ((constructor)) and __attribute__ ((destructor)).

I haven't tried it, but you might be able to make a shared library on linux via adept -c foo.adept and manually gcc -shared -o libfoo.so foo.o.

The reason why init/deinit is required right now it that it forces you to consider whether you are using global/static variables. If you do end up using global/static variables that require dynamic initialization and don't use init/deinit then your program will not behave as expected, which could result in difficult to solve bugs if the programmer wasn't aware of it.

Hopefully we can eventually eliminate this requirement though.

[ghost]

Same syntax could be used on Windows, with the extension changed to .dll: gcc -shared -o libfoo.dll foo.o. If you forced me to have init function and deinit function then I will just use gcc.

[IsaacShelton]

Yes that's probably the best way to do it right now if you want to avoid them