Mundane C tricks ...

[revelator]

is also the reason why libtool sometimes is needed though even a lot of linux users hate it with a passion it does make the job easier, on windows it can be somewhat annoying though since you need a posix shell for it to work and a few things dont quite work the same way as on linux.

[taniwha]

Heh, while building shared libs in Linux is fairly easy, getting it right is difficult enough I'd rather leave it to the tools (that's what their there for). More importantly, in the unlikely event that shared lib building changes, I probably don't need to do anything because libtool will handle it.

I never understood the hatred for the autotools.

[mh]

[revelator]

It can be a bit steep to learn to use autotools but i think the main reason is incompatibilities with older versions (can be a real bitch updating them after patching) libtool itself is ok though it works a lot better in linux, it does sometimes screw up in windows. One bugger that been haunting me was with older libtool packages it sometimes couldnt tell if the library was an import library for a dll so i had to override it by putting lt-cv-deplibs=pass_all in a cache file to have it link, many users would be somewhat lost trying to figure out tricks like that

[revelator]

Ofc mh but it takes time sometimes a lot to find out where it went wrong
To make matters worse im quite a novice with C++ so it makes it a bit harder to learn the ins and outs

[taniwha]

While I had to learn a lot to make good use of autoconf and automake, I've had very little trouble with it, and I've been maintaining QF's auto* usage from the beginning. Most of the issues I've seen were caused by improper quoting, and that's caused by devs not reading the docs . I had QF's auto* stuff working with both ancient and new autotools until a year or two ago when I decided I wanted to use some of the newer features.

My only gripe was auto* is very slow for QF, but QF has a stupid number of Makefile.ams (88 in my local tree), and a crazy number of checks. There was a time where a naive use of automake's conditionals caused an N-squared blowout that was very painful (and I think we had just 3 makefiles then), but I found a workaround for that.

[revelator]

Happy it worked so well for you its not often i see problems with autotools but it does occasionally happen mostly with automake macros which in newer versions sometimes have altered macro names while some older versions used checks that newer versions dont have anymore try updating the gcc tree hehe belive me thats a lesson in patience since most gcc distros
want a specific version of autotools and wont accept any other. Recent gcc distros have updated to a later version now but i remember one of the more recent versions would only accept autotools 1.5 which is damn ancient and any attemt of updating would screw you over so bad you had to redownload the whole package.
Gtk also suffered from the above at some point but recent versions have improved somewhat.
All in all i think it does an ok job most of the time but when it screws up you sometimes have to sift the net for hours trying to figure out how to fix it

[Spike]

Personally I stick with gmake, because its what I know.
Saves me grubbing around with m4/bash/make/headers/etc nonsense.

Autoconf's forté is in making source packages compile on systems that its never been tested on. Its only natural that it will then fail occasionally and then be hated due to its incomprehensible opaque magic macros that mean nothing to us mere mortals.

[taniwha]

[revelator]

Rofl hit the nail on the head with that one spike these days i mostly use CB for setting up dependencies and tell it to spit out a makefile ready to go. And the stuff i cannot easily do that with i just use my preconfigured site script to get over the nasties that sometimes pop up when using Msys/MinGW 90% of the time i dont need to do jack to make it compile, the last 10% i can usually handle cause i picked up some tricks over the years. Ccache was one of the flunkies i needed to get nasty with but i must have done a proper job as even today its still the only windows version i know of that works 100%.

Ok a small trick in C i remember is checking for zero termination in a string with if (string[0] == '\0') instead of
if (strlen(string) == 0) safes us calling a runtime function for a simple check and just checks the first char for termination

The above actually made me wonder since i had a discussion with one of ID's devs about zero terminating an array of const strings his version ended with a cast that like this const ((void *)NULL) while i just used '\0' both ways worked even though he ment it was incorrect so i read up from bjarne stroustrup (the man who created C++) the funny thing was that according to him my method was perfectly valid as '\0' is a const integer 0 and in C++ NULL is 0 and not a pointer like in some C compilers.
Both methods work and are valid but i think mine looks a little less scary

[Spike]

c programmers have to cast from 0 to a pointer, you get a warning otherwise.
c++ does it automatically, but it has to be an immediate or constant or something.
remember folks, always prototype your functions or your compiler will **** you over.

The reasoning here is that void* is not universal in C, thus (void*) in your NULL definitions would mean you couldn't use it for anything other than void* pointers. I guess they decided to make non-pointers the universal pointer. Sums up c++ nicely.

for code correctness, you should never use '\0' to refer to a pointer. Not because the compiler cares, but because of readability. Character constants *should* be character constants and specific to strings (or individual chars), not randomly used for pointers. Which is why I would personally have rejected your fix as it was. I really don't get the point of their extra cast - NULL should already be a void* in C, and shouldn't matter in C++.

[taniwha]

[Baker]

[revelator]

Aye in that regard its probably better to write it like that the cast i think was because it was terminating an array of const chars that was allready cast the same way (compiler warning i bet but havent tried without the cast and im in thailand so its hard to check atm).

[mh]

I always use NULL too - "somevar = 0;" is just ambiguous about what type "somevar" is. NULL makes it more explicit. Practicality over pretties any day.