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]

C++ error messages make me cringe

Fortunately when you get 40 pages of garbage error output it's usually a pretty good indicator that you've done something bad either with STL or your own templated code. Doesn't tell you what the bad thing is but at least you can narrow it down.

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

Spike: haha, too true.

My favorite feature of autotools: out-of-tree builds are available by default. I use it all the time with QF (to the point where .gitignore gets stale, oops). I even abuse it for QF's cross-compile scripts: have a sub-directory in the source tree where I run cross-configure.sh and cross-make.sh, cross-configure.sh creates and configures two sub-directories in that sub-dir: one for a native build (for qfcc and pak), and one for the target build. cross-make.sh then checks for the native dir and if present builds it then the target dir, otherwise just builds where it is (so I can use the script in deeper sub-dirs).

Code: Select all

quakeforge/
    libs/
    ...
    m.o/    <- .o so git ignores it (*.o in .gitignore)
        cross-configure.sh -> ../tools/cross/mingw/cross-configure.sh
        cross-make.sh -> ../tools/cross/mingw/cross-make.sh
        native/
        i686-pc-mingw32/

Cross scripts for droid, mingw, mipsel-linux, and ps3-elf. All use the same mechanism.

Heh, from C tricks to autotools tricks

[edit]Neat thing about my setup: if I don't symlink the scripts (there's no requirement to, it's just convenient), I should be able to do all four cross builds in the one dir, then native gets built only once (but configured 4 times :/).

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

I haven't really used NULL since I started using C++ back in 91 or so. I almost always use 0. C (gcc, anyway) has accepted 0 for pointers for a very long time.

I almost never use '\0', even for strings. To me, '\0' is a char, but the terminator on strings is not. I might occasionally use if (!strlen(str)) (rarely if (strlen(str) != 0)), but I will usually use if (!str[0]) or if (!*str).

To me, 0 is the universal "nothing", I guess: "no object here", "no more chars here", "no, none of that either".

QF won't compile without prototypes

Code: Select all

gcc -DHAVE_CONFIG_H -I. -I../../../../libs/util/test -I../../../include -I../../../../include    -g3 -O2  -frename-registers -finline-limit=32000 -Winline -ffast-math -funroll-loops -fomit-frame-pointer -fexpensive-optimizations -fstrict-aliasing -pipe -Wsign-compare -Wlogical-op -Wall -Werror -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fno-common -MT test-quat.o -MD -MP -MF .deps/test-quat.Tpo -c -o test-quat.o ../../../../libs/util/test/test-quat.c

[Baker]

I haven't really used NULL since I started using C++ back in 91 or so. I almost always use 0.

I almost never use '\0', even for strings.

I use NULL for pointers, '\0' for char due to data type clarity when reading code. If you see == '\0' or = '\0' it smacks you in face "hey, this is a char datatype" and likewise for a pointer I try to use == NULL or != NULL instead of "if (!something)"

i.e. Ability to look at code and get picture of what is going on,

+ ability to tell what most vars are without looking at declaration (or using IDE hover or what not).

[Probably picked this up after reading lots of other code and noticing that time to interpret what each var is doing is time lost ... Seeing if (!x) doesn't tell me much about x, but seeing if (x == NULL) I immediately know what it is ... ]

(Annoyance: Why did people used to use Hungarian notation *AND* shittily name the variables cryptically? What an annoying combination ... haha. Gee I can tell what the datatype is, except I have no idea what the F the variable is for ... What a combo! I wonder if that was what killed Hungarian notation? Which was an "ok" idea I guess ... maybe still has some merit for pointers and booleans in some occasions like function prototypes?]

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