Thanks, the halt was what I was looking for
I'm encountering some strange bug where my policy objects rank doesn't match
the distribution's rank though I've double checked they should... Both defined
as param. I'm trying to get some information via compilerError, however
printing integer variables doesn't seem to work. For example
var i:int = 3;
compilerError("Error: "+i);
results in:
error: unresolved call 'compilerError(string)'
$CHPL_HOME/modules/internal/ChapelBase.chpl:162: note: candidates are:
compilerError(param x: c_string ...?n, param errorDepth: int)
$CHPL_HOME/modules/internal/ChapelBase.chpl:166: note:
compilerError(param x: c_string ...?n)
Replacing compilerError with halt compiles, but of course isn't what I would
have needed...
As I wrote above, I have a problem where a domain assignment fails because
incompatible dimensions. In the base class of my policy I have method
setBoundingBox overridden by MyPolicy. The distribution calls this function. If
I comment out the assignment and replace it with printed diagnostics the
dimensions match, so somehow the inheritance confuses the compiler.
I tried the method of not using a base class at all, however it proved it own
difficulties. Essentially, I need to be able to store the policy in objects,
and getting classes to store generic object requires a lot of changes. But I
guess I'll have to go down this route...
So should the following work or do I need something more, or are there simpler
ways to do this?
class MyBlockDist {
type policyType;
var policy:policyType;
....
}
proc MyBlockDist.MyBlockDist (...
policy,
policyType = policy.type,
...) {
this.policy = policy;
...
}
29.01.2015, 22:11, "Brad Chamberlain" <[email protected]>:
>> For now I have defined functions meant to be overridden by user as
>> functions with empty body. However I'd like to issue some diagnostics if
>> these empty functions are called, either at compile- or runtime.
>> Something along the lines of die("message") or exit("message"). I tried
>> compilerError, but apparently it generates an error regardless whether
>> the method is overridden or not.
> Ultimately what we need here is a true notion pure virtual methods in the
> language, but see the apology below about "naive OOP support".
>
> compilerError() is triggered at compile-time any time the compiler tries
> to resolve that function call, so using it in dynamic dispatch cases is
> not the right way to go, at least as the compiler is currently implemented
> (it'll analyze a virtual method whether or not all child classes override
> it). So typically in these cases, we insert a halt() in the pure virtual
> method which will result in an execution-time error. Not as ideal as a
> compile-time error, but our only option I'm aware of until pure virtual
> methods are supported.
>
> -Brad
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
