Simplify some C-style code (page 3)

enum DomainType { Ball, Box, CsgDiff } struct Domain(int Dim) { DomainType type; union { Ball!Dim ball; Box!Dim box; CsgDiff!Dim csgDiff; } this(Ball!Dim ball) { this.type = DomainType.Ball; this.ball = ball; } this(Box!Dim box) { this.type = DomainType.Box; this.box = box; } this(CsgDiff!Dim csgDiff) { this.type = DomainType.CsgDiff; this.csgDiff = csgDiff; } void doSomething() { switch (type) { case DomainType.Ball: ... break; case DomainType.Box: ... break; case DomainType.CsgDiff: ... break; } } }

1 day ago

Re: Simplify some C-style code

Posted by sfp
in reply to Christian Köstlin

Permalink

sfp

Posted in reply to Christian Köstlin

Permalink

On Sunday, 5 January 2025 at 16:02:47 UTC, Christian Köstlin wrote:

On Wednesday, 25 December 2024 at 07:49:28 UTC, sfp wrote:

I have some code like this:

enum DomainType {
  Ball,
  Box,
  CsgDiff
}

struct Domain(int Dim) {
  DomainType type;
  union {
    Ball!Dim ball;
    Box!Dim box;
    CsgDiff!Dim csgDiff;
  }

  this(Ball!Dim ball) {
    this.type = DomainType.Ball;
    this.ball = ball;
  }

  this(Box!Dim box) {
    this.type = DomainType.Box;
    this.box = box;
  }

  this(CsgDiff!Dim csgDiff) {
    this.type = DomainType.CsgDiff;
    this.csgDiff = csgDiff;
  }

  void doSomething() {
    switch (type) {
    case DomainType.Ball:
      ...
      break;
    case DomainType.Box:
      ...
      break;
    case DomainType.CsgDiff:
      ...
      break;
    }
  }
}

Is there some way I can reduce the amount of boilerplate using D, i.e. generate most of this code at compile time?

For what it's worth, I had checked out SumType as an alternative to this mess, but it doesn't play nicely with recursively defined types.

What would speak against coming up with an interface (https://dlang.org/spec/interface.html) the only includes this doSomething method and then having Ball, Box and CsgDiff implementing that.
Almost no boilerplate involved, no manual union and type storing, but a virtual function call for doSomething.

It's "very" OOP, which gets less and less popular, but why not?

Kind regards,
Christian

I have another post here about virtual opBinary for interfaces.

Main two reasons at this point:

I don't want to be tied into D's OO + GC impl unnecessarily.
I've figured out how to do multiple dispatch using mixin templates at this point and I'm basically happy with the result (there is room for improvement but I'm confident in my ability to make those improvements now).

But I agree that interface is a good choice for many things. It would unfortunately lead to quite a lot of boilerplate for what I'm working on and it's unclear whether the performance tradeoff is acceptable (I have seen other projects make a similar tradeoff bit fail becsuse they were unable to tame their exploding memory use).

Forums