4 ms·

Fortunatley I've never surpassed 15,000 lines on a personal project!

moonchild 6y ago
Still, though, your incremental builds will be much faster if you avoid unity builds. Full rebuilds are rare (assuming your build system knows about header dependencies, which it should). Unity builds also make it hard to do abstraction or information hiding well. There's a form of polymorphism in c I describe at [1] which requires separation of translation units. 1. https://comp.lang.c.narkive.com/aa5pZoND/polymorphic-oop-hack https://comp.lang.c.narkive.com/aa5pZoND/polymorphic-oop-hac...
- glouwbug 6y ago
  True, but I typically build with link time optimizations (-flto) since I do a lot of software rendering, and this really hurts incremental builds too. I'll checkout your link, but as for polymorphism I've had good luck with doubly linked lists holding void pointers, and routinely writing maps / filters with #define foreach(node, list, ...) for(Node* node = list->head; node; node = node->next) __VA_ARGS__ And using it along the lines of void Move(List* units) { foreach(node, units, { Unit* unit = node->data; unit->position.x += unit->speed.x; unit->position.y += unit->speed.y; } } Or something along the lines of that
  - moonchild 6y ago
    > link time optimizations Ah, fair enough. (Personally, I don't generally find that the performance delta between having lto on|off is worth the compile time. Maybe for release builds. But usually performance is jut not that much of a concern; I don't bother.) void Move(List* units) { foreach(node, units, { Unit* unit = node->data; unit->position.x += unit->speed.x; unit->position.y += unit->speed.y; } } My approach doesn't enable anything fundamentally different from this. But it makes it more ergonomic and safer.
    - glouwbug 6y ago
      I see your point with opaque pointers though. They are great for code obfuscation when shipping libraries, and totally do require a header / source file split making unity builds not an option. It always amazes me how C can reach the height of most modern languages with a bit of (serious) effort.

Still, though, your incremental builds will be much faster if you avoid unity builds. Full rebuilds are rare (assuming your build system knows about header dependencies, which it should). Unity builds also make it hard to do abstraction or information hiding well. There's a form of polymorphism in c I describe at [1] which requires separation of translation units. 1. https://comp.lang.c.narkive.com/aa5pZoND/polymorphic-oop-hack https://comp.lang.c.narkive.com/aa5pZoND/polymorphic-oop-hac...

glouwbug 6y ago
True, but I typically build with link time optimizations (-flto) since I do a lot of software rendering, and this really hurts incremental builds too. I'll checkout your link, but as for polymorphism I've had good luck with doubly linked lists holding void pointers, and routinely writing maps / filters with #define foreach(node, list, ...) for(Node* node = list->head; node; node = node->next) __VA_ARGS__ And using it along the lines of void Move(List* units) { foreach(node, units, { Unit* unit = node->data; unit->position.x += unit->speed.x; unit->position.y += unit->speed.y; } } Or something along the lines of that
- moonchild 6y ago
  > link time optimizations Ah, fair enough. (Personally, I don't generally find that the performance delta between having lto on|off is worth the compile time. Maybe for release builds. But usually performance is jut not that much of a concern; I don't bother.) void Move(List* units) { foreach(node, units, { Unit* unit = node->data; unit->position.x += unit->speed.x; unit->position.y += unit->speed.y; } } My approach doesn't enable anything fundamentally different from this. But it makes it more ergonomic and safer.
  - glouwbug 6y ago
    I see your point with opaque pointers though. They are great for code obfuscation when shipping libraries, and totally do require a header / source file split making unity builds not an option. It always amazes me how C can reach the height of most modern languages with a bit of (serious) effort.