Compiling with VS2015

[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]

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".

[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]

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]

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]

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.

[Siemelink]

It's probably trailing comma?

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

Willem.

[t4nk]

static const char *desc_stat_pos[] =
{
#define STAT(a, b, c, d, e, f, g, h) f,
#include "list-stats.h"
#undef STAT
};

static const char *desc_stat_pos[] =
{
"strong",
"smart",
"wise",
"dextrous",
"healthy"
};

It's probably trailing comma? Note that macroexpanded code looks like this:

        ...
	"dextrous",
	"healthy", /* the comma */
};

[Pete Mack]

Rather than including basic.h, add /DWINDOWS to the compile options.

[Siemelink]

You might need to include win/readdib.c if it's there as a file to compile.

Thanks again. I had the file included but for unknown reason WINDOWS was not defined. So the whole file was commented out with #ifdef. I fixed this by adding #include "h-basic.h"

So finally, I can compile without error. The game runs, I can start new or load a save file. I have the main window and the subwindows. But as soon as a dungeon is generated, the game crashes.

I still have a compiler warning on the code below: Expected an expression. This probably means that the array is expanded as {}

static const char *desc_stat_pos[] =
{
#define STAT(a, b, c, d, e, f, g, h) f,
#include "list-stats.h"
#undef STAT
};

The warning goes away if I expand this by hand.
static const char *desc_stat_pos[] =
{
"strong",
"smart",
"wise",
"dextrous",
"healthy"
};

I see that the method to define an array using an #include is repeated aplenty. Expanding everything by hand would be a mess, so now my next quest is to configure this code for the funky compiler.

Willem.

[takkaria]

Oh, that made a difference!
Now I only have one more nut to crack, a linker error:

unresolved external symbol _FreeDIB referenced in function _Term_xtra_win_react

Neither of those keywords means something to me.

Willem.

You might need to include win/readdib.c if it's there as a file to compile.

[Siemelink]

Your problem is that you shouldn't be compiling get.c or get.h, they're not used. They should be removed, I think that's my fault that they're still there.

Oh, that made a difference!
Now I only have one more nut to crack, a linker error:

unresolved external symbol _FreeDIB referenced in function _Term_xtra_win_react

Neither of those keywords means something to me.

Willem.

[takkaria]

Your problem is that you shouldn't be compiling get.c or get.h, they're not used. They should be removed, I think that's my fault that they're still there.

[Pete Mack]

get.c, line 54

[Siemelink]

MSVC doesn't have stdbool.h
You can write your own, then add -I. to the compile line.
http://stackoverflow.com/questions/5...s2010-question

Angband has h-basic.h, which defines bool as well:

/* Use a char otherwise */
typedef char bool;

#undef TRUE
#undef FALSE

#define TRUE 1
#define FALSE 0

#endif

replacing the typedef with #define bool char seems to recover bool.

But the order of includes seems off. get.h gives errors in the getset definition, bool is not defined. I can add #include "h-basic.h" in get.h to get a bit further.

Then I am stuck on item_filter, which is not defined anywhere, in any file.

bool get_item(struct object **choice, const char *pmt, const char *fail, cmd_code cmd, item_filter filter, int mode);

Confusion reigns!