Forum Replies Created
-
Posts
-
@Gerry Quinn and dawlane: The template issue isn’t actually a thing. For regular usage of C++’s templates, ‘typename’ and ‘class’ mean the same thing.
I don’t believe ‘struct’ is even a thing with templates, you just write ‘typename’ or ‘class’ and it works with anything. Trying to use ‘struct’ with C++ templates in GCC results in compilation error while ‘class’ works fine.
As for Monkey 2’s code generation, it literally doesn’t matter. Well, unless you absolutely want consistent or good looking compiler output. At that point nobody would be happy anyway.
Makes sense. Although, this also means that from the perspective of the programmer, the template is largely superficial. In other words, if interfaces weren’t reference-only, then ‘data-based interfaces’ could be used the same way, only allowing for tighter constraints, which would help reduce unknown behavior.
Basically, my perspective is that, like templates, the compiler could generate multiple versions based on the provided type (In the case of static uses or structs).
Then, from the perspective of Monkey, you would be purposely restricting yourself to the feature-set of the interface. In addition, like generic functions, you could take in class-based types as well.
The idea is that interfaces could be used to simplify the syntax for mundane generic routines, with self-applied restrictions. It would be less typing by the authors, and the same amount of typing for the users.
Then again, this all seems possible with templates, so it’s not like this can’t already be done. Although, it would help keep code stricter for the times you don’t need function templates.
It may be syntactic sugar, but it’s actually similar to what’s been discussed for concepts in C++ over the last few years.
At any rate, thank you for verifying the intended behavior.
That’s only the case in Monkey 2, which takes a similar approach to D.
Basically, the mindset is that ‘Structs’ should be used to represent POD (Plain-old data), with some nice syntactic sugar. Although in Monkey 2’s case, it’s not pulling any punches about what you can do with a ‘Struct’. In Monkey’s case, it cares about where you use them.
In C++, structures and classes are inherently the same, with the implication being that most (But not necessarily all) ‘structs’ will have a simplistic memory layout. Thanks to heavy usage in this manor, and long-time C compatibility, this is how they stand without added complexity, like virtual functions/methods and inheritance.
With that said, however, the difference between classes and structures in C++ is superficial, usually an indication of intended design patterns, rather than a core difference.
To put it simply, structs in C++ are just public by default, with no other differences. The extra meanings come from design philosophies popularized by C.
In contrast, Monkey 2, that is, in actual MX2 code, not translator output, structures are dedicated types used for copy-based manipulation. Basically, this means they live on the stack, or more specifically, their context (Scope).
They’re meant to be treated the same way integers, floats, and strings were in Monkey 1. Sure there’s side effects to using them; shallow copies, for example, have potential safety concerns, but they’re not all bad.
Perhaps the most interesting part about Monkey 2’s ‘Structs’ is that they’re allocated where they stand. This means an array of structures is allocated all in one area, which is not only faster, but it also lets you map out an area of memory however you like.
It’s not just arrays that benefit from this; you could also use ‘Structs’ inside of classes. For example, you could allocate a vector without needing to use the garbage collector. This is great because it means that an object can have its position held locally, where it can’t be easily changed by something untrusted.
This also means that providing interfaces for APIs is easier, and there’s no potential overhead from constantly looking around in memory.
Not to mention that operations on the structure become a lot more simplistic, allowing you to make as many objects as you want, without ever needing to worry about your memory footprint.
There’s more to be said about structures and how they’re used with regards to things like ABI compatibility and expected layouts, but that’s a topic for another day.