4 ms·

> If a container level variable is const then its value is comptime-known, otherwise it is runtime-known. I'm not sure how to reconcile that Zig documentation

> If a container level variable is const then its value is comptime-known, otherwise it is runtime-known. I'm not sure how to reconcile that Zig documentation with your comment's claim. It appears that Zig relies on opportunistic behaviors here instead of contracts. That is, your var foo could be comptime known, but isn't required to be. Which is fine enough, but not comparable to `constinit` either. Alternatively if all container variables are exclusively comptime initialized, then the obvious missing part from Zig would be the inverse of constinit which is the onload initializer behavior.

anonymoushn 4y ago
The quoted documentation says if you initialize a mutable variable to 5 at compile time and later change it to 2 and print it, it won't print 5, because uses of that variable in expressions won't be resolved to the constant value used to initialize it at compile time. When is onload? I don't think that's a time that occurs during program execution in Zig.
- kllrnohj 4y ago
  Does Zig not have an equivalent of `__attribute__((constructor))`? If not then that'd be the 3rd type of initialization it's missing, the equivalent of C++'s nothing specified.
  - ori_b 4y ago
    It's relatively easy to solve the problem in a language with acyclic imports by doing a topological sort of the imports, and initializing in that order. In C++, with textual includes and no standardized control over the linker, you don't have the information or well-defined control to order the initialization, so you have a problem.
    - jcelerier 4y ago
      Okay but we're talking about native languages where you are bound by the rules of your platform's dlopen / LoadLibrary implementation ; this is where so many static initialisation bugs lurk, when you load libraries dynamically
      - ori_b 4y ago
        No, you're not. The fact that a misfeature exists in the toolchain doesn't force you to use it. You can order the init sections on your own when you generate the binaries and add your own constraints, and if your toolchain doesn't give you that control, you can generate and call your own init functions. (Since I didn't want to dick with the linker too much, I generated my own init functions in my natively compiled language to solve this problem). Your language's dlopen wrapper can also dlsym the initializer and call it if it's present. This is very much a C++ problem, because its separate compilation model throws away initializer ordering, and prevents the compiler from doing anything about it. And, of course, compatibility makes this a tough sell for C++ -- languages unconstrained by history don't have to worry about this. tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main.
        kllrnohj 4y ago
        > tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main. How does my shared library do that?
        ori_b 4y ago
        def loadlib() { lib = dlopen("libfoo.so") sym = dlsym(lib, "pkgname.__init__") sym() return lib } Hell, you can even do this with a single constructor attribute that runs the initializer, if you want to be fully dlsym compatible. If you have a DAG of dependencies, it's impossible for your library to care whether main or dlopen has called its initializer, because the same initialization order of dependencies is observed in either case. The only thing you need to beware of is guarding against double-init if you dlopen, and the generated library-level initializer code can do that.
    - kllrnohj 4y ago
      If it was "relatively easy" then there wouldn't be a million dependency injection solutions for Java of ungodly runtime cost to try and solve this problem. People want to initialize stuff at load library time. They will always want to do this. If the language doesn't provide a solution, people will just bolt on shitty add-on toolchains to do it anyway. This isn't a uniquely C++ problem (__attribute__((constructor)) is after all for C, not C++). Take for example Rust, which also doesn't provide an attribute((constructor)) equivalent and says nothing happens before or after main. Except https://crates.io/crates/ctor https://crates.io/crates/ctor exists to immediately say "fuck that noise" and racked up >20m downloads.
      - ori_b 4y ago
        > If it was "relatively easy" then there wouldn't be a million dependency injection solutions for Java of ungodly runtime cost to try and solve this problem. You realize Java has the feature you're discussing, without dependency injection? class Foo { static { initialize(); } } They even have a well defined execution order: https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm..., section 8.7, with order defined in section 12.4
        kllrnohj 4y ago
        That runs at class load time, not at library/executable load time as c++ static constructors or __attribute__((constructor)) does. So no, that's not equivalent. Not even close. This is why you see things in Java that scan through loaded jars looking for all classes with attributes to just speculatively load. To recreate what c++ has natively & C has with a broadly supported extension.

anonymoushn 4y ago

The quoted documentation says if you initialize a mutable variable to 5 at compile time and later change it to 2 and print it, it won't print 5, because uses of that variable in expressions won't be resolved to the constant value used to initialize it at compile time. When is onload? I don't think that's a time that occurs during program execution in Zig.

kllrnohj 4y ago
Does Zig not have an equivalent of `__attribute__((constructor))`? If not then that'd be the 3rd type of initialization it's missing, the equivalent of C++'s nothing specified.
- ori_b 4y ago
  It's relatively easy to solve the problem in a language with acyclic imports by doing a topological sort of the imports, and initializing in that order. In C++, with textual includes and no standardized control over the linker, you don't have the information or well-defined control to order the initialization, so you have a problem.
  - jcelerier 4y ago
    Okay but we're talking about native languages where you are bound by the rules of your platform's dlopen / LoadLibrary implementation ; this is where so many static initialisation bugs lurk, when you load libraries dynamically
    - ori_b 4y ago
      No, you're not. The fact that a misfeature exists in the toolchain doesn't force you to use it. You can order the init sections on your own when you generate the binaries and add your own constraints, and if your toolchain doesn't give you that control, you can generate and call your own init functions. (Since I didn't want to dick with the linker too much, I generated my own init functions in my natively compiled language to solve this problem). Your language's dlopen wrapper can also dlsym the initializer and call it if it's present. This is very much a C++ problem, because its separate compilation model throws away initializer ordering, and prevents the compiler from doing anything about it. And, of course, compatibility makes this a tough sell for C++ -- languages unconstrained by history don't have to worry about this. tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main.
      - kllrnohj 4y ago
        > tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main. How does my shared library do that?
        ori_b 4y ago
        def loadlib() { lib = dlopen("libfoo.so") sym = dlsym(lib, "pkgname.__init__") sym() return lib } Hell, you can even do this with a single constructor attribute that runs the initializer, if you want to be fully dlsym compatible. If you have a DAG of dependencies, it's impossible for your library to care whether main or dlopen has called its initializer, because the same initialization order of dependencies is observed in either case. The only thing you need to beware of is guarding against double-init if you dlopen, and the generated library-level initializer code can do that.
  - kllrnohj 4y ago
    If it was "relatively easy" then there wouldn't be a million dependency injection solutions for Java of ungodly runtime cost to try and solve this problem. People want to initialize stuff at load library time. They will always want to do this. If the language doesn't provide a solution, people will just bolt on shitty add-on toolchains to do it anyway. This isn't a uniquely C++ problem (__attribute__((constructor)) is after all for C, not C++). Take for example Rust, which also doesn't provide an attribute((constructor)) equivalent and says nothing happens before or after main. Except https://crates.io/crates/ctor https://crates.io/crates/ctor exists to immediately say "fuck that noise" and racked up >20m downloads.
    - ori_b 4y ago
      > If it was "relatively easy" then there wouldn't be a million dependency injection solutions for Java of ungodly runtime cost to try and solve this problem. You realize Java has the feature you're discussing, without dependency injection? class Foo { static { initialize(); } } They even have a well defined execution order: https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm..., section 8.7, with order defined in section 12.4
      - kllrnohj 4y ago
        That runs at class load time, not at library/executable load time as c++ static constructors or __attribute__((constructor)) does. So no, that's not equivalent. Not even close. This is why you see things in Java that scan through loaded jars looking for all classes with attributes to just speculatively load. To recreate what c++ has natively & C has with a broadly supported extension.