Earlier quoted context omitted.
If someone is using a C++ feature it's because they think the feature is better than not using it. std::string lets you treat strings as easily as ints — subject to a run–time cost. You can make libraries that make strings easier to use in C, but you can't make one that makes them as easy as ints.
But it does not have to be "as easy as int" to be able to be productive in C. Almost as easy is sufficient.
I write games in C (yes, C) (2016)
271–280 of 288 posts
Re: I write games in C (yes, C) (2016)
#272Earlier quoted context omitted.
You can make strings (or bignums or matrices) more convenient than the C default but you can never make them as convenient as ints, while in C++ you can.
Yes, but I do not think this is a good thing. A programming language has to fulfill many requirements, and convenience for the programmer is not the most important.
Re: I write games in C (yes, C) (2016)
#273Earlier quoted context omitted.
I’ve seen this play out a lot. People say they “write games in C” and then quietly rebuild half of C++ anyway with vtables in structs or giant switch statements, just without the compiler helping. That’s fine if it makes you happier, but it’s not obviously simpler or safer. Also, C++ compile times are mostly a self-inflicted wound via templates and metaprogramming, not some inherent tax you pay for having virtual fun…
It's important that you do these things yourself before you utilise the compiler to do them for you, so you have real understanding.
Re: I write games in C (yes, C) (2016)
#274Earlier quoted context omitted.
Oh, I see what you meant now. I don't think it works: ./test: line 1: hlt: command not found ./test: line 2: jmp: command not found Do you get a dopamine hit out of this?
No, that is right, assembly doesn't work in what looks like the output of a Unix shell. Assembly is intended to be input to an assembler. Easy mistake to make, I suppose.
Well, fine. Doesn't build. Says somehow about undefined symbol _main
Re: I write games in C (yes, C) (2016)
#275Earlier quoted context omitted.
No, that is right, assembly doesn't work in what looks like the output of a Unix shell. Assembly is intended to be input to an assembler. Easy mistake to make, I suppose.
But I don't want to use an assembler. Well, fine. Doesn't build. Says somehow about undefined symbol _main
Re: I write games in C (yes, C) (2016)
#276I need RAII and refuse to debug ugly macros as a workaround. The STL isn't perfect but it's a good guiding principle.
You should try writing something serious in C just for the hell of it. And without RAII-like macros. Write all your allocs and frees.
It's an ongoing struggle!
Re: I write games in C (yes, C) (2016)
#277I write mostly like I would in C, but use C++ features as needed. It ends up looking similar to Rust if you squint. All these "I write games in C" people complain about C++ features, and then end up reimplementing virtual interfaces manually with struct headers or massive switch statements, just to feel better about themselves. Writing games in C is not harder, you just have to implement modern language features by h…
> then end up reimplementing virtual interfaces manually C++ dynamic dispatch (your "virtual interfaces") is achieved by welding a vtable onto every type and providing a pointer to that vtable for instances of the type. If in 90% of your code you deal with specific types like Goose or Swan or Duck or Seagull, and only 10% needs to work with the broad Bird category well, too bad, every Goose, Swan, Duck and Seagull ca…
You can get exactly what you are asking for in C++ using techniques of static polymorphism and CRTP pattern (https://en.wikipedia.org/wiki/Curiously_recurring_template_p... and https://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick) along with traits and dynamic dispatch (if needed).
For great examples of the above, see the classic Scientific and Engineering C++: An Introduction with Advanced Techniques and Examples by Barton & Nackman (1994).
Re: I write games in C (yes, C) (2016)
#278Re: I write games in C (yes, C) (2016)
#279Earlier quoted context omitted.
> then end up reimplementing virtual interfaces manually C++ dynamic dispatch (your "virtual interfaces") is achieved by welding a vtable onto every type and providing a pointer to that vtable for instances of the type. If in 90% of your code you deal with specific types like Goose or Swan or Duck or Seagull, and only 10% needs to work with the broad Bird category well, too bad, every Goose, Swan, Duck and Seagull ca…
Your example is disingenuous. What you are stating is the obvious trivial way of doing something when your objective is actually quite different. You can get exactly what you are asking for in C++ using techniques of static polymorphism and CRTP pattern ( https://en.wikipedia.org/wiki/Curiously_recurring_template_p... and https://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick ) along with traits and dynamic dispa…
Re: I write games in C (yes, C) (2016)
#280I write mostly like I would in C, but use C++ features as needed. It ends up looking similar to Rust if you squint. All these "I write games in C" people complain about C++ features, and then end up reimplementing virtual interfaces manually with struct headers or massive switch statements, just to feel better about themselves. Writing games in C is not harder, you just have to implement modern language features by h…
C++ reimplements a lot of the things we do in C with function pointers, while hiding what's actually happening behind topheavy syntax that implies a 1990s object oriented paradigm that's dead now.
Have you bothered to look how GCC and clang are implemented?