www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template visibility

reply Ethan Watson <gooberman gmail.com> writes:
https://github.com/Remedy-Entertainment/binderoo/blob/master/binderoo_client/d/src/binderoo/typedescriptor.d

Inside that is some code I have to translate D types to the C++ 
strings that we expect.

I'm in the middle of making a mathematical vector class that I 
will be sticking in Binderoo, but maps functionality to our 
internal SIMD vector class. As such, to keep Binderoo a clean 
interface for anyone to use, it will not contain any  CTypeName 
UDAS for Remedy-specific type info.

The problem comes when I try to alias to the expected type for 
our D code and provide a C++ string override, like so:

//----------------------------------------------------------------------------
module remedy.rl.simdvector;

public import binderoo.math.vector;
public import binderoo.typedescriptor;

alias SIMDVector = binderoo.math.vector.VectorFloat;

enum CTypeNameOverride( T : SIMDVector ) = "r::SIMDVector";

pragma( msg, CTypeString!( SIMDVector ) );
//----------------------------------------------------------------------------

The CTypeString template has no visibility to my 
CTypeNameOverride, and as such that pragma prints out 
"VectorFloat" instead of "r::SIMDVector".

Is there some way to mitigate this without needing to resort to 
mixins everywhere?  This is one of those things in C++ where if I 
specialise a template, any invocation of the template after that 
point will go to the specialised version. But in this case, 
because instantiation happens within the scope of the 
binderoo.typedescriptor module instead of within the scope of the 
module the template is invoking from, it just can't see my new 
CTypeNameOverride specialisation.

I do have other instances inside the Binderoo code where I 
resolve the module names for symbols and mixin an import for that 
to make it all just work, but I'm getting tired of having to do 
that every time I come across this problem.
Aug 31 2016
next sibling parent Ethan Watson <gooberman gmail.com> writes:
On Wednesday, 31 August 2016 at 12:45:14 UTC, Ethan Watson wrote:
 I do have other instances inside the Binderoo code where I 
 resolve the module names for symbols and mixin an import for 
 that to make it all just work, but I'm getting tired of having 
 to do that every time I come across this problem.
I also realised that won't work in this case, as getting the module of the SIMDVector alias will infact get the module binderoo.math.vector. std.typecons.Typedef might work out just fine in this case to do that with though.
Aug 31 2016
prev sibling parent David Nadlinger <code klickverbot.at> writes:
On Wednesday, 31 August 2016 at 12:45:14 UTC, Ethan Watson wrote:
 But in this case, because instantiation happens within the 
 scope of the binderoo.typedescriptor module instead of within 
 the scope of the module the template is invoking from, it just 
 can't see my new CTypeNameOverride specialisation.
This analysis is correct, and no, there is no direct way of emulating argument-dependent lookup (or the existence of a single global scope, for that matter) in D. You have to funnel in the information via the template parameter somehow, as you did with UDAs. An alternative solution might be to make the your binderoo library use an explicit context, where such overrides can be registered manually at the point where both it and the vector library in question are in use (i.e. the client library/program). One option for this would be explicit context arguments, another to wrap the API into one giant template which injects that extra information (`alias myBinderoo = binderoo!(overrides, ...); myBinderoo.doSomething!foo(bar);`). — David
Aug 31 2016