Hi,
I'm trying to get AngelScript working in the C4 Engine and am getting the following error messages when I compile:

stdlib.h(599) : error C2485: '__restrict' : unrecognized extended attribute

Microsoft Visual Studio 9.0\VC\include\new(58) : error C2084: function 'void *operator new(size_t,void *)' already has a body

enginecode\C4PrefixWindows.h(1391) : see previous definition of 'new' new(63) : error C2084: function 'void operator delete(void *,void *)' already has a body

enginecode\C4PrefixWindows.h(1401) : see previous definition of 'delete'

Microsoft Visual Studio 9.0\VC\include\xlocale(342) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc

Do you have any suggestions as to how I can get around them? I assume he has these settings in C4 for a good reason, so is there any way I can make AngelScript work with C4?

this doesn't seems to be an issue with angelscript itself.
have you tried removing angelscript includes? does it compiles?

It compiles and runs okay. I did a search on this error and found the comment below and it seems to fit, because there is a header file where he #defines restrict as __restrict. In this file he lists different platforms C4 supports, so I figure he is doing for a good reason.

http://www.codeproje...485-__rest.aspx

I would expect it to be the other way around, VS2005 to recognize __restrict and VC6 not to if anything.
Check that your source isn't intended to be compiled with GCC/glibc which makes extensive use of __restrict. As the error is showing in stdlib.h a standard header file I'm guessing something you've included before stdlib.h has messed with the Compiler by doing something like a #define __declspec or a #define restrict. I've only ever seen that sort of thing when someone is attempting to get cross compatibility with GCC. It's just a guess though, could be something else entirely. [/quote]

How are you compiling AngelScript? Are you compiling it as a library, or did you put all the source files together with the C4 source files?


In AngelScript I use the placement new operator extensively to allow custom memory management. It seems that this is conflicting with how C4 is using the placement new operator. If the projects are compiled separately it really shouldn't be a problem, but if you have to compile both projects together, you may need to make some adjustments to the code, either in AngelScript or in C4 to allow them to live together. If you decide to adjust the code, you'll find the use of the placement new operator in the as_memory.h header file.


I don't use exception handling in AngelScript, but there shouldn't be any problem in you turning it on for your project.


I don't use the keyword restrict or __restrict in AngelScript, so I have no idea where this problem is coming from. Perhaps there is a project settings that predefines restrict at global level. This is the only explanation that I can think of.

How are you compiling AngelScript? Are you compiling it as a library, or did you put all the source files together with the C4 source files?[/quote]

Thanks for replying.

I first tried compiling as a static lib and when that didn't work, I put all the source in with the C4 source.

BTW I just put the angelscript.h include above all C4 includes and the stdlib errors went away. Now only the new and delete errors remain. So what I'll do is try and compile it as a static lib and see if it works that way.

Okay I got AngelScript compiling. Thanks for you help guys.

Now the only issue I have left is getting the addons working.

I added the addons to the angelscript project and compiled the angelscriptd.lib, but am getting the same errors as before as soon as I #include them. If I comment the addon includes out, it works.

#include <angelscript.h>
#include <scriptstdstring/scriptstdstring.h>
#include <scriptbuilder/scriptbuilder.h>

error C2084: function 'void *operator new[](size_t,void *) throw()' already has a body.


Any further suggestions?

I'll try to help. You could also handle addons by compiling them separate from the core library. This is how I handle them for my project and I haven't had a single problem as of yet.

I'll try to help. You could also handle addons by compiling them separate from the core library. This is how I handle them for my project and I haven't had a single problem as of yet.

It seems the problem occurs whenever <string> is included. The C4 guy does not want people using it for some efficiency reason. So the only way I can see I'd be able to use those addons, is if I re-write them using C4's string class?

If C4 is using its own string class and you plan to expose C4's functionality to the script then it is probably better to rewrite the desired add-ons to use this class instead of std::string.

This is exactly why angelscript doesn't have a built-in string type, so the application can pick and choose the best implementation.

If C4 is using its own string class and you plan to expose C4's functionality to the script then it is probably better to rewrite the desired add-ons to use this class instead of std::string.

This is exactly why angelscript doesn't have a built-in string type, so the application can pick and choose the best implementation.

Thanks for your help.