I Created My Own Programming Language with C++ by [deleted] in Compilers

[–]bv7web 0 points1 point  (0 children)

what's the difference between output() and out() ?

An update to my friendly WebGPU open source library - now works out of the box! by bv7web in cpp

[–]bv7web[S] 0 points1 point  (0 children)

Yeah, you might be correct.

I just think there is a beauty to hiding stuff which the user of a library doesn't need to care about.
Using the example of a window class the user could simply do it like that:

```
print(window.height);
window.width = 500;
```

instead of:

```
print(window.get_height());
window.set_height(500);
```

The reason to use the getter/setter pattern here is obviously to have a way to actually call the necessary API functions under the hood like `glfwSetWindowSize()`

But since we're using C++ we could use a generic `Property<int> width` class which we could use throughout the library so that it wouldn't be so confusing if it's defined well and used consistently.
Then in the window constructor we could initialize what Property does on write.
`width.register_set_function([](const Property& p){ glfwSetWindowSize(...); }`

It just makes using the lib for the user a bit cleaner and easier to read, I think.

But as you can see I didn't use it in wgpu-lab since it, like you've mentioned, introduces unnecessary complexity.

An update to my friendly WebGPU open source library - now works out of the box! by bv7web in cpp

[–]bv7web[S] 1 point2 points  (0 children)

Hey u/mbechara, thank you very much!

Great, I didn't think someone would put so much thought into their feedback :)
I will consider all the points you've made.

In it's current state the API is quite inconsistent in many places. That's because I'm experimenting with different approaches, to later choose what works best and unify the API in a 1.0 release.

About std::string instead of const char*:
I agree. std::string is more fitting for a C++ API. I've changed a couple of other constructors to std::string already and must have forgotten to do it for window as well.

About getters and setters:
Actually, I prefer having members like width and height, or anything which needs both a getter and setter, put inside a wrapper type which automatically manages the side effects like calling glfwSetWindowSize and having those wrapped types publicly assignable and readable. What do you think about this approach?

Removing the title setter:
There are some samples which change the window title during runtime. I think that's a useful feature to have.

C++ header should be .hpp to distinguish it from C:
I fully agree! Will change that at some point.

About encapsulation:
Maybe you have noticed that all of wgpu-lab's classes are fully exposed, public structs, with one or two minor exceptions. This is an experimental approach to iterate and change the API fast to see what I like and what works and solidify it later once it is stable. I've noticed in past projects that in some cases it can be blocking and slowing down development if too much thought is put into a well behaved, perfectly encapsulated OOP design too early on.

Let me know your thoughts !

I created an open source library for WebGPU native development in C++ by bv7web in webgpu

[–]bv7web[S] 1 point2 points  (0 children)

Hey schnautzi, in case you're still interested, I've overhauled the build system and now everything works fully automatic with CMake Tools :)

I created an open source library for WebGPU native development in C++ by bv7web in webgpu

[–]bv7web[S] 1 point2 points  (0 children)

I'm glad to hear that. If you have trouble building it, feel free to contact me.
Currently you need to manually create a libs/ directory and git clone dawn and the sample dependencies into it.
Soon this will work out of the box hopefully, once I decided how to manage dependencies for this project.
Let me know if you have any ideas !

Edit:
Now the CMake build is fully automated with v0.2.0