Please cover the topic how to create something like a Rust trait in Zig. To be more precise - a compile-time checked static dispatch pattern of defining shared type behavior. Thanks!
That's a good idea, there have been some blog posts and videos in the past about interfaces and dispatch in Zig, so I'll be researching those to see what I can put together.
exe.addCSourceFile(.{ .file = b.path("src/math.c") }); exe.root_module.addIncludePath(b.path("src")); this is what I had to do to make it work on 0.14.0
Yes a future topic of alignment and pointers in more detail would be interesting. In the meantime, @ptrCast lets you convert one pointer type to another like say a *f64 to a *u64, which is another way of reinterpreting memory without changing it. @alignCast lets you change the alignment of a pointer, which is the power of 2 memory boundary multiple where the pointer can start.
So when using the extern option of exposing the functions in the c lib, can these be namespaced, so you can reference them like: my_math_funcs.increment(...) etc?
I wonder how zig handles the case when you are using 2 linked libs and they both have a function with the same signature ... will the compiler complain? How will it know what function to use?
"Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3." -- Linux Kernel Coding Style www.kernel.org/doc/html/v4.10/process/coding-style.html
What is this? It is much easier to integrate C and C++, at least in the C++ direction. Is this about automatically object compiling and linking multiple languages? If so it is considerably dirtier than integrating C and C++ or C and D. If it is about the abilities of the Zig compiler, then what will happen if you have C libraries that you don't have the source code to? I presume Zig is good, because it isn't Rust that has an insane cult of young people that knows nothing about programming paradigms and such thing as maintainability and readability, but this video is confusing. Select one purpose: either integration - which include object compilation and linking - or the zig compiler tool, and demonstrate the selected purpose!
The title says it all: "Working with C". I could definitely cover each of the topics in separate videos though, maybe an idea for the future. On using C libraries with source unavailable, you just statically or dynamically link to them, it's a one-liner in build.zig.
Please cover the topic how to create something like a Rust trait in Zig. To be more precise - a compile-time checked static dispatch pattern of defining shared type behavior. Thanks!
That's a good idea, there have been some blog posts and videos in the past about interfaces and dispatch in Zig, so I'll be researching those to see what I can put together.
With 0.13 "exe.addIncludePath(.{ .path = "src" });" is not working?!
Yes, it's now exe.root_module.addIncludePath(b.path("src"));
You can also do exe.addIncludePath(b.path("src/"));
exe.addCSourceFile(.{ .file = b.path("src/math.c") });
exe.root_module.addIncludePath(b.path("src"));
this is what I had to do to make it work on 0.14.0
Correct! Thanks for sharing.
Can you please cover some of the built-in functions like @ptrCast @alignCast I found them several times in the std library code.
Yes a future topic of alignment and pointers in more detail would be interesting. In the meantime, @ptrCast lets you convert one pointer type to another like say a *f64 to a *u64, which is another way of reinterpreting memory without changing it. @alignCast lets you change the alignment of a pointer, which is the power of 2 memory boundary multiple where the pointer can start.
So when using the extern option of exposing the functions in the c lib, can these be namespaced, so you can reference them like: my_math_funcs.increment(...) etc?
Good question. Haven't tested it, but if you put the extern fn inside a struct or another file that you @import, you should be able to do it.
I wonder how zig handles the case when you are using 2 linked libs and they both have a function with the same signature ... will the compiler complain? How will it know what function to use?
here's an example I wrote
bindings.zig:
pub const math = struct {
pub extern fn add(a: i32, b: i32) i32;
pub extern fn increment(a: i32) i32;
};
main.zig:
const std = @import("std");
const math = @import("bindings.zig").math;
pub fn main() !void {
const a = 1;
const b = 2;
const c = math.add(a, b);
std.debug.print("{d}
", .{c});
std.debug.print("{d}
", .{math.increment(c)});
}
3:33: Wow! 8 spaces is a grotesque indentation. 4 is standard.
"Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3." -- Linux Kernel Coding Style www.kernel.org/doc/html/v4.10/process/coding-style.html
Raise your hands if you are here too after all the zig optimism but with `c_uint` vs `c_int` confusion 🤐
What is this? It is much easier to integrate C and C++, at least in the C++ direction. Is this about automatically object compiling and linking multiple languages? If so it is considerably dirtier than integrating C and C++ or C and D. If it is about the abilities of the Zig compiler, then what will happen if you have C libraries that you don't have the source code to? I presume Zig is good, because it isn't Rust that has an insane cult of young people that knows nothing about programming paradigms and such thing as maintainability and readability, but this video is confusing. Select one purpose: either integration - which include object compilation and linking - or the zig compiler tool, and demonstrate the selected purpose!
The title says it all: "Working with C". I could definitely cover each of the topics in separate videos though, maybe an idea for the future. On using C libraries with source unavailable, you just statically or dynamically link to them, it's a one-liner in build.zig.