Compiling with VS2015

[Siemelink]

Hi all,
I am trying to compile 4.0.5 with microsoft visual studio community 2015. I am getting loads of errors.
There is the old instruction to compile, it is not quite accurate. My exact project settings are in the attachment.

1)
I've added all the .h and .c files, the files in the win folder. When I compile i receive eror: macro definition of snprintf conflicts with Standard Library function declaration

This code seems outdated, so I've commented it out snprintf:
/**
* Native MSVC compiler doesn't understand inline or snprintf
*/
#ifdef _MSC_VER
# define inline __inline
//# define snprintf _snprintf
#endif

2)
Next, I get that pwd.h is not added. But I find the #include <pwd.h>under UNIX, while I am trying to compile as WINDOWS

So I've added || defined(_MSC_VER) to gain:
/**
* Extract the "WINDOWS" flag from the compiler
*/
# if defined(_Windows) || defined(__WINDOWS__) || \
defined(__WIN32__) || defined(WIN32) || \
defined(__WINNT__) || defined(__NT__) || defined(_MSC_VER)
# ifndef WINDOWS
# define WINDOWS
# endif
# endif

3)
now I am left with 100s of errors. I like this one:

static const int list_size = 64;
const char *initial_pronoun;
const char *name_list[list_size];

"Expression (list_size) must have constant value," which has been defined just two lines above!

There is probably something obvious that I missed. Does someone have a clue?

Thanks, Willem.

[Pete Mack]

MSVC is known not to be fully compliant in c99. You can change the const int to a #define with no bad effects.

[t4nk]

Maybe just don't use a C++ compiler to compile a program that is not written in C++

[Pete Mack]

MSVC does work for C, it just never was updated fully to later standards. I don't know why. Adding that kind of thing to a compiler is pretty easy.

[Siemelink]

MSVC does work for C, it just never was updated fully to later standards. I don't know why. Adding that kind of thing to a compiler is pretty easy.

Yes, I've been using MSVC for over a decade to compile angband.

It does not seem to like nested typedefs, #typedef char bool gives errors where bool is used. If I replace bool with char, it does compile. But clearly doing that throughout the code is not optimal.

Willem.

[Pete Mack]

MSVC doesn't have stdbool.h
You can write your own, then add -I. to the compile line.

http://stackoverflow.com/questions/5680340/c-doesnt-have-a-bool-also-vs2010-question

[t4nk]

MSVC does work for C

For some definition of "C"...

it just never was updated fully to later standards. I don't know why.

https://docs.microsoft.com/en-us/visualstudio/#pivot=languages

Pretty self-explanatory, IMO...

[AnonymousHero]

I feel that this the perfect moment to chime in and say that Angband should convert to C++. C'mon, people!

/trolling

EDIT: FWIW, the quality of the MS compilers for C or C++ are appalling. (I mean they're trying to catch up... and getting a lot better, but they're still nowhere near Clang or GCC in terms of rapid compliance to new standards.)

[t4nk]

I feel that this the perfect moment to chime in and say that Angband should convert to C++. C'mon, people!

Well that's not a bad idea. It might not be a practical idea, but I do think C++ is more appropriate for software like Angband (even though it's a horrible language )
Actually, you know what. How about converting it to D

[Derakon]

Actually, you know what. How about converting it to D

C++ makes a modicum of sense here because you can do the upgrade piecemeal. If you're going to completely rewrite the game in a different, incompatible language, you might as well do a top-down redesign. And write it in Python. Oh look, it's Pyrel again. Too bad I ran out of steam before getting it all the way finished.

[t4nk]

C++ makes a modicum of sense here because you can do the upgrade piecemeal. If you're going to completely rewrite the game in a different, incompatible language, you might as well do a top-down redesign.

That's why I thought of D (and not something else). It's about as compatible as C++ is ("extern (C)"...), and less nasty.
Also, Angband is a normal procedural program and I don't see any particular reason to change that radically.

And write it in Python.

As if Python is such a gift... I hate Python

[AnonymousHero]

And write it in Python.

Ha. Ha. Ha. That's a noob language that nobody uses!!111one

Just to be a little constructive: I actually have a little experience in converting an existing code base from C to C++ and it does actually work out pretty smoothly[1]. Of course, there's a lot of code and it takes quite a long time to even get the basic things converted. (The pain was doubled because I first had to get rid of the Lua code by converting to plain C. "Fortunately" the Lua code was already very C-like, so it was doable. Painful but doable.)

One thing I feel very strongly about is that any large scale project must have static type checking. Maybe it's just me, but I believe very strongly in Type-driven Design... even if C++ is kind of an anemic and horrible language to do it in.

[1] I find that C++ is actually a reasonably nice language these days (post-C++14 with good-constexpr), but YMMV.

EDIT: Actually, I'd like to add: Even if nothing further comes from it, I think Pyrel was definitely a worthwhile experiment.

[AnonymousHero]

@t4nk: I actually thought seriously about using D "back in the day", but honestly: At the time it was extremely niche, but even today it's (unfortunately) still quite a niche language.

Overall I do think that D might be a better language if you want to do metaprogramming (an obvious win in Angband-like code, I feel), but C++ is catching up via "static if" and constexpr...

[Derakon]

EDIT: Actually, I'd like to add: Even if nothing further comes from it, I think Pyrel was definitely a worthwhile experiment.

I'm inclined to agree, and I think that it made major inroads on data-driven gameplay at a time when all spell effects, spells in spellbooks, etc. were still hardcoded in Vanilla. The container-driven "dungeon database" was also a neat concept -- you could basically query for specific categories of things in the dungeon by doing a series of set intersection operations, which made it easy to do things like "give me all of the evil monsters" or "give me all of the flammable items in this square".

In principle I believe its approach to equipment modifiers was also an interesting experiment; I'm just sad that it never reached the point where it could really be playtested.

Re: strong typing, with a project of this size, I agree, having typechecking is a must. Python does allow you to annotate variables with types and has for ages; back in 2008 I had a game project where I made a 2D coordinate tuple type that was at least an order of magnitude faster than the untyped version. But having the capability is not the same thing as mandating its use, of course.

[AnonymousHero]

...

+1, agree with, basically, everything. Btw, are you married to anyone right now?

(EDIT: That was a joke, just btw.)