Nightly build of the development trunk

[OvermindDL1]

Guess when I get time I need to find all the dependencies it needs.  Which reminds me, is there a list of *all* the dependencies I need to get?

Also, would you mind any patches that get rid of variadic macro's and replace them with C/C++ compiler portable code so I do not have to make a hundred or so changes each time I update from source?  I could make windows build for you as well if things work better with VS as well.

[EvilGuru]

Also, would you mind any patches that get rid of variadic macro's and replace them with C/C++ compiler portable code so I do not have to make a hundred or so changes each time I update from source?  I could make windows build for you as well if things work better with VS as well.

VA macros are needed. Take a look at lib/framework/printf_ext.h (namely sasprintf) which is a stack-allocating variant of sprintf. Since it needs to allocate memory on the stack there is no non-macro way of doing it.

When we implemented it we did consider compiler support, but since all major compilers supported VA macros (and // comments, the only C99 features we use to the best of my knowledge). It might be better if you looked into a way of getting VS to use an alternative compiler (MSVC 2005's is known to work, as is GCC).

Regarding Windows builds you definitely want to speak to Buginator, who is also an MSVC user. I know he has been working on the project file recently trying to get it to use static libraries to eliminate the "DLL hell".

Regards, Freddie.

[OvermindDL1]

I have never had any issues with DLL Hell that others have, but then I proactively help prevent against it.  Now Manifests, those are the new, worse DLL Hell.

Honestly I replaced the things with C++ constructs, but what if I changed the macro's to have their arg count in the name (ASSERT0, ASSERT1, ASSERT2, etc...).  I'll do it, and it would work everywhere easilly...

As stated, I use VS2k3 though as I have had bad annoyances with manifests.  I would rather deal with real DLL's any day then manifests.  Also that 2k3 has been shown to compile smaller and faster code then 2k5, since they did not change the C++ compiler except adding manifests support and other stupidity (mostly just .NET stuff) in that version (and in 2k8, they are getting behind...).  2k3 was the first one worth using however.

So Buginator, what are all of the dependencies?

[EvilGuru]

but what if I changed the macro's to have their arg count in the name (ASSERT0, ASSERT1, ASSERT2, etc...).  I'll do it, and it would work everywhere easilly.

That is rather ugly. The only time when that kind of thing is acceptable (IMO) is when function overloading is available (so it is transparent to the programmer). Since VS2K3 is the only compiler affected, and you are (to the best of my knowledge) the only one using VS2K3 and implementing your proposed changes would inconvenience 5+ devs it really doesn't seem worth it. If it were a problem affecting more compilers, I would at least give it a bit more thought.

Regards, Freddie.

[OvermindDL1]

If you used a C++ compiler (and no, I do not mean C++, just a compiler, which it seems like you all are), then I could just make those into C++ constructs, it becomes even far more powerful then, along with type safety and numerous other things.

[EvilGuru]

Our coding guidelines state that all code should compile as C++ (should be ever decide to switch). So if you are having trouble compiling it as such then feel free to fix/file bug reports. Then you can modify your local project to compile it as C++.

Regards, Freddie.

[DevUrandom]

Do our guidelines say that? I currently don't see a sense in preparing now for a switch to C++ which might never happen... We should discuss that point of the guidelines again...

[EvilGuru]

We follow the C89 standard since we want the code to be compilable with C++ compilers. We use variadic macros and C99 comments though (which are ISO C++ as well as C99).

Although it is worth noting that we do *not* cast the return value from malloc/alloca.

Regards, Freddie.

[Per]

IIRC we decided that the code should compile with a c++ compiler using the equivalent of gcc's -fpermissive option. Since this does not cost us much (cannot use some C99 stuff), I see no reason to go back on that.

[OvermindDL1]

'Technically', the C++ standard does not support C99 constructs like variadic macro's, hence why VS2k3 has that 'plausible deniability" thing, even though C99 had been out for years and all the others supported it.  Although the next version of C++ will support C99 constructs, and a lot more (thank god for the 'auto' keyword, will help shorten templates quite a bit).

And I had no warnings/errors with any memory allocation lines, so it seems VS2k3 does not have an issue with that.

[Per]

Will the next version of the C++ standard support variable size arrays? Like this:

Code: Select all

int size = 50;
{
    int array[size];
}

That is one feature from C99 that I really miss.

[DevUrandom]

Afaik lots of stuff from C99 is backported into C++0x, and I think this is one of those.

[OvermindDL1]

The next version of C++ supports all of C99, and then quite a bit more.

[Kamaze]

...and then quite a bit more.

Boost.

[DevUrandom]

Boost.

Yes, some stuff from Boost may be included in the standard as well.