symbols. So let the users use them that way. There's no need to
force them to type out the namespace all the time. It's
certainly not an OOP vs. procedural issue, as namespaces have
nothing to do with OOP.
Thanks, appreciate your perspective.
The example shows calls to `update()` in the setters and in the
constructor. The D method for binding this looks like `void
sfShape_update(sfShape* shape);`.
Ur a legend bro...
It fixed it...
Calling this in the `Rectangle` constructor:
```D
class RectangleShape : Shape {
this(Vector2f s
On Tuesday, 24 January 2023 at 08:18:53 UTC, thebluepandabear
wrote:
On Tuesday, 24 January 2023 at 06:32:35 UTC, Christian Köstlin
wrote:
On 24.01.23 04:59, thebluepandabear wrote:
Regards,
thebluepandabear
Btw I understand this question is extremely complex, don't
want to pressure anyone t
On Tuesday, 24 January 2023 at 09:54:01 UTC, frame wrote:
Thanks! it works well with the `-op` switch, didn't know I can
do with libraries. Only drawback is that every path now stored
as absolute path - any way to store only a relative one?
Ah never mind, it seems only to do this with phobos
On Tuesday, 24 January 2023 at 08:15:55 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 24/01/2023 8:59 PM, frame wrote:
Also why have most objects an unique postfix in the name but
those files havn't? It's mostly a `__ModuleInfoZ` or `__initZ`
but not always.
Symbols which end in __ModuleIn
On Tuesday, 24 January 2023 at 06:32:35 UTC, Christian Köstlin
wrote:
On 24.01.23 04:59, thebluepandabear wrote:
Regards,
thebluepandabear
Btw I understand this question is extremely complex, don't
want to pressure anyone to help me because of that... but any
sort of assistance or leads woul
On 24/01/2023 8:59 PM, frame wrote:
Also why have most objects an unique postfix in the name but those files
havn't? It's mostly a `__ModuleInfoZ` or `__initZ` but not always.
Symbols which end in __ModuleInfoZ are symbols that hold per-module
information for features like unittests and module
When creating a linker library under Windows and having module
a/b/foo.d but also d/c/foo.d the linker afterwards is bailing out:
.lib(foo.obj) : warning LNK4255: library contain multiple
objects of the same name; linking object as if no debug info
And when I did inspect the library it confir
