Jump to content

  • Log In with Google      Sign In   
  • Create Account

- - - - -

shared issues


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 TheAtom   Members   -  Reputation: 330

Like
0Likes
Like

Posted 02 April 2012 - 04:17 PM

Tested with AS rev 1176 (and can't see anything about fixing these in the commitlog).

1. The following gives "Can't return value when return type is 'void'." upon compilation:
shared int f()
{
	return 0;
}

2. imported functions are always considered non-shared and thus are unusable in any shared code. Perhaps imported functions should be always treated as shared, or maybe it could be done explicitly:
import shared int f() from "module";


Sponsor:

#2 Andreas Jonsson   Moderators   -  Reputation: 3455

Like
0Likes
Like

Posted 02 April 2012 - 06:23 PM

Thanks. I fixed this bug now, in revision 1262.


Imported functions are not 'shared'. This is because the imported functions are dynamically linked individually per module. Imported functions will also access the global variables in the originating module. To be 'shared' the function (or other entity) cannot have any module specific behaviour.

It is possible to import a function that is shared by another module, but then you hide the fact that the function is shared.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

#3 TheAtom   Members   -  Reputation: 330

Like
0Likes
Like

Posted 02 April 2012 - 08:05 PM

What would be wrong with checking if an imported function used by a shared code is shared upon bind time, and giving a bind error if it isn't?
// module mod1
shared void f1() { }
void f2() { }

// module mod2
import void f1() from "mod1";
import void f2() from "mod1";
shared void g()
{
	f1();
	f2(); // bind error on this one when BindAllImportedFunctions()
}


#4 Andreas Jonsson   Moderators   -  Reputation: 3455

Like
0Likes
Like

Posted 03 April 2012 - 09:53 AM

The actual bind id is still module specific, so the function g() cannot be compiled in a module independent way.

What exactly are you trying to accomplish? Perhaps there is an easier way. If the function already is shared, then there is not really any need to import it. Simply declare it again as shared, and it will be the same function.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

#5 TheAtom   Members   -  Reputation: 330

Like
0Likes
Like

Posted 03 April 2012 - 11:51 AM

I have a few large modules that serve as a general API for every scripted ingame feature, coupled with a header script for each one of them that is nothing more than a wall of imports (plus macros and interfaces used). Then, I have some utility classes inlined in several modules (I'd like them to be shared for that reason) that use those headers. While I could simply put the function bodies in said headers to make it work, it is not an option: our headers are readily available to a larger group of people who do not have the access to the modules themselves, for security reasons (at best they receive them in a binary form; but generally they can only send new scripts to an isolated testing environment and run stuff remotely). Of a lesser importance is that the code would be somewhat uglier.

#6 Andreas Jonsson   Moderators   -  Reputation: 3455

Like
0Likes
Like

Posted 03 April 2012 - 01:26 PM

I think in this case you can take advantage of an undocumented feature: A shared function is not re-compiled if it finds a pre-existing function from another module. The same goes for classes, interfaces, and enums.

Using this you can can declare the shared function with an empty body in the header that you distribute to your clients. The main module will provide the true implementation.

shared int f() {}
shared class c {}
shared interface i {}
shared enum e {}

You just need to make sure the large module that has the real function implementation is always compiled before any other modules that will only have the empty function, class, interface, or enum.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

#7 TheAtom   Members   -  Reputation: 330

Like
0Likes
Like

Posted 08 April 2012 - 11:46 AM

That's what I'm going to do. Thanks.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS