Compiling with VS2015

[Pete Mack]

Don't bother. There are a lot of these lists in .h files; many are included more than once using different transformation macros. There is no clean way to remove the trailing comma in those cases. Disable the warning with a pragma if you really care.

Yes.
When I compiled the snippet separately I could get the warning and also the correct contents from the array.

Willem.

[AnonymousHero]

Don't bother. There are a lot of these lists in .h files; many are included more than once using different transformation macros. There is no clean way to remove the trailing comma in those cases. Disable the warning with a pragma if you really care.

Yeah, I think this another one of those C99 things that MS never bothered to implement?

[Pete Mack]

No. It's a warning message that is occasionally (rarely) useful, but not in the case of generated code. Like any warning message, you can disable it. It's not C99 at all; it's part of the original K&R spec.

[AnonymousHero]

No. It's a warning message that is occasionally (rarely) useful, but not in the case of generated code. Like any warning message, you can disable it. It's not C99 at all; it's part of the original K&R spec.

Really? I stand corrected, I guess. I just remember something vaguely similar in C99-vs-C89 discussions.

[Pete Mack]

It turns out to be surprisingly hard to get an answer on this. There are claims both ways, including that it was left out of C89 by accident, and added to C90. It was certainly part of K&R. Here's the most definitive answer I found.

https://bytes.com/topic/c/answers/217042-comma-end-initializer-allowed

Scroll down to Dan Pop's answer, Nov 14, 2005

It turns out I was wrong: it was a standard C feature since "day one",
i.e. since K&R1 was printed. Retained by the standardisation committee
because "it provides flexibility in adding or deleting members from
an initializer list, and simplifies machine generation of such lists".

[t4nk]

@t4nk: I actually thought seriously about using D "back in the day", but honestly

Hey, AnonymousHero. After a reasonably thorough investigation, I came to the conclusion that you're right.
Still, it is our moral duty and obligation as programmers to avoid inflicting any more C++ on the world
Rust is the next on my list of newflangled languages to investigate
All I want is a better C... specifically, C with better memory management, better strings and better arrays (including associative arrays), but with full C interop. Better C++ would also be acceptable... Rust is most likely isn't it, but we'll see.

P.S: I must say, though, that the D language itself is great, just the implementation is lacking. I will revisit it in a year or so, hopefully there will be some improvements...

[Pete Mack]

Well, there are Java and C#. Both have better strings than C.

[t4nk]

But how do I run them without their gigantic runtimes Those might be better, but they're not C, so they don't qualify as "better C".
Also, performance is not good enough (pls no microbenchmarks...)

[Pete Mack]

Yeah, the runtime libraries are pretty ridiculous, I agree. But the performance is probably good enough for roguelikes.

[Derakon]

If you can make a playable roguelike in Python or GameMaker, you can do it in Java or C#. The performance complaint about Java was kind of valid when it first came out, but they've had two decades to optimize the runtime now. It's plenty fast.

[t4nk]

^Hey, guys, I'm not talking about roguelikes, more like in general. BTW, I'm not actually going to rewrite Angband in anything

[Nick]

BTW, I'm not actually going to rewrite Angband in anything

Well, you've already rewritten a fair chunk of it in C...

[AnonymousHero]

Another option which might be interesting would be to target browsers directly with something like Scala.js.

EDIT: It has quite a big "runtime" (scala-library-as-js), but if you have game assets anyway they would probably dwarf that.

[t4nk]

Another option which might be interesting would be to target browsers directly with something like Scala.js.

EDIT: It has quite a big "runtime" (scala-library-as-js), but if you have game assets anyway they would probably dwarf that.

Why are you always suggesting some bizarre functional languages like Racket, Haskell and now... Scala? ...js?
Anyway, Rust is pretty interesting, but it's verbose, full of Ocaml-isms (I don't see any particular advantages in them) and poorly documented. It's probably a good replacement for Ada.
I also changed my opinion on D again It's more general purpose than Rust, the flaws have workarounds and, all in all, Angband should be rewritten in D

[AnonymousHero]

Why are you always suggesting some bizarre functional languages like Racket, Haskell and now... Scala? ...js?

Well, they're good languages .

(Scala less so, but still a lot better than most things. Especially things that can target JS.)

Anyway, Rust is pretty interesting, but it's verbose, full of Ocaml-isms (I don't see any particular advantages in them) and poorly documented. It's probably a good replacement for Ada.

Algebraic Data Types + pattern matching are absolutely amazing when you want to model a domain, though. (That plus traits, in the case of Rust.)

Not sure if D can do ADTs, but you can probably hack something similar using macros.